[thelist] JavaScript traps - need input for article

[Peter Barrett]

Hm. I don't suppose this counts as an expert tip, but I'm interested in
what wisdom others on the list have to pass on, so I'll try a couple to
start the ball rolling:

	1. Simplicity. JS developers worry about character count (code
size), and runtime evaluation as performance killers. The other day, I
ran across a line of code in a site I maintain that looked like this:

	function foo ( value ){
		value = eval("'"+value+"'");
	...

	wow. This was too good. I put the line in comment & kept it in
the code (archive version - we use a script to strip out comments before
deployment) to bring it to the attention of the other fellas on my team
(the original author was no longer around, or I would have spoken to him
personally rather than put his code up for -er- comment).

	The example is interesting, because the author is trying to
ensure that value is cast as a string (as JS is an untyped language), in
the most convoluted way I've ever seen. First off, he's adding single
quote characters to the string. Actually, the result of that is a
guaranteed string anyway, and appending '' is a perfectly valid way of
getting the desired result. Then, at runtime, evaluating the value in
quotes, so that it's a string again. Eval is very expensive compared to
the append method above. Also, toString is defined as a base method of
Object, so value.toString(); would have been just as good, and perhaps
more readable to a novice.


	2. Functions are Data. While this principle can be used to
easily create tons of impossible-to-maintain self-modifying code, this
principle also allows for reflection (via the for/in loop, or closer to
the metal, inspecting the actual string that defines a function) and, as
I discovered, a great way to add metrics gathering.

	For example, when asked to improve the performance of the JS
framework that I'm maintaining, I wrote a small module that, at runtime,
gathers up all of the user-defined functions, and redefines them with
calls to logging facilities to each function. One sweep of use (very
slow, of course), and you have metrics on which functions are called
most often, when, *relative* timing (not as good as absolute, as all
those debug calls throw it off, but still useful), return values, etc.
	This is a pretty neat feature, because I don't need to add all
of those debug statements by hand (~10K lines of JavaScript in total on
this site/webservice), which would need to come out before deployment
anyway. Sure it runs terribly slowly, but it's for debug, so who cares?
Now I can just include the file with other JS on any page I want to
test... No maintaining any extra script. I found a few bottlenecks I
hadn't suspected, I don't have to maintain the modified code - it gets
tossed each time, and it's useful to any JS package that my team writes
in the future. Some of the best code re-use I've ever gotten.

My two cents. I look forward to hearing some other thoughts.

Cheers!
~pete





-----Original Message-----
From: Liorean [mailto:Liorean at user.bip.net]
Sent: Wednesday, October 09, 2002 1:21 PM
To: Evolt Thelist
Subject: [thelist] JavaScript traps - need input for article


[Resent since I need more input]

Hello Folks!

I'm writing up an article on the traps for a javascript programmer, and
I need input on possible things to take into count. The article will
also includes things that aren't really traps (they work), but that can
be done better in other ways. It's also intended to include a bit of
tips on increasing the performance of scripts.

So, please give me some input. Give me some stuff to put into the
article!

(Note that this isn't one of those "Ten most usual errors in javascript"
articles with a target audience of people intending to learn javascript.
It's intended target audience is intermediate to expert javascript
programmers.)

// Liorean, waiting for input

--
For unsubscribe and other options, including
the Tip Harvester and archive of thelist go to: http://lists.evolt.org
Workers of the Web, evolt !