Re: RFD: How To Recognize Bad Javascript Code

On Tue, 01 Jan 2008 18:01:51 +0100, Thomas 'PointedEars' Lahn wrote:

Jeremy J Starcher wrote:
Have I missed the mark on a point or two?
Have I overlooked something?

Plenty.

1. "Depreciated script tag usage"

a. The word you were looking for is _deprecated_, not "depreciated".

Absolutely correct. Thought I spell-checked everything. I'll fix that.


b. The term you were looking for is `script' _element_, not "tag".
Elements consist of tags (start tag, close tag) and content:

http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1

Once again correct. I've let myself get a bit sloppy in speech.


c. Your example `script' elements are empty where they should have
content. At least that should be indicated in some way.

Hadn't thought of that, but it makes sense.


d. "JavaScript1.2" actually means something in NN4; ask Google.
I have never seen anyone using "JavaScript1.3", though.

I didn't know if that was backwards compatible to browsers today or not.
If memory serves me correctly, it changes some of the array methods.


2. 'Using "href:javascript"'

| Using the pseudo-protocol javascript in the href is never valid. Not
| only is such code not valid HTML, [...]

Wrong. The value of the `href' attribute is of type URI. If
`javascript:' syntax would be written as an URI, it would certainly
be valid there. One point of recommending against `javascript:'
there is that

| it cannot provide a fallback to browsers not running Javascript.

There are other points that I have also mentioned in my FAQ notes last
year. There are also exceptions to be made in special cases.

Hmmm... This point has me thinking now. I'll have to ponder the best way
to phrase the URI issue. "Valid, but not recommended" perhaps.

I'll try and find your FAQ notes. If you are feeling generous I'll take a
donated URL to it.

3. "Excessive use document.write"

should read "Excessive use *of* document.write()".

Agreed, once again. Bad proofreading on my part again.

A recommendation for a viable alternative is missing. Consider this:

<script type="text/javascript">
if (NN4 || IE4)
{
document.write(
new Array(
'<ul>',
' <li><a href="Search.html">Search<\/a><\/li>',
' <li><a href="Order.html">Order<\/a><\/li>');
' <li><a href="Help.html">Help<\/a><\/li>');
'<\/ul>'
).join("")
);
}
</script>

I'll agree that is better than the table design, but I was trying to
indicate that using Javascript for putting a navigation bar on the screen
shouldn't be done. Augmenting one would be OK.

Perhaps a different example would be better. Using Javascript to show a
print button or something.

4. 'Not ending lines in a semi-colon ";"'

The argument in favor of the trailing `;' is flawed in two regards:
a) not every line should be ended with a semicolon but every *statement*;

I code in C. I know that. Somewhere it got lost between brain and
keyboard. Maybe I've been using "one statement per line" scripting
languages too much.

b) minifiers should not be used. See previous discussions.

I knew that was going to come up. I'm tempted to yank that whole section
out, except that style-wise I -really- like having the semicolon there.
Code without it grates on me.

5. "Use of eval"

| Using eval to parse JSON works well. While there are some security
| concerns, they can be easily addressed.

There are two other uses where using eval() is considered appropriate.
One is making arbitrary computations with user input,

Yes, I should mention that. While I've only seen it used for "trivial"
calculator applications, I suppose it would be the basis for an Javascript
spread*** or something.

the other is
hiding code from script engines that consider it to be syntactically
invalid because they do not support the corresponding language feature.

Oh.. there is an idea. That is the second new thought you've tossed into
my head here. I'm picturing one code branch that runs slowly with a dozen
checks to assert all values are within range and a second code branch
using try/catch. The try/catch is faster when available.

Is that the kind of thing you mean?


A reasoning for the statement that the security concerns could be
easily addressed is missing.

I'll toss in this link: <URL: http://www.json.org/json2.js > In my
reading, I haven't heard of anyone finding holes in it.

6. "Browser sniffing"

You describe the goal of that -- "to tell which browser the code is
running on" to be "good", and I don't agree. Web developers should
avoid writing for a specific user agent.

Poor wording on my part. No, its not good. Recognizing that all the
world is not IE and that differences exist *is* good.

7. "Web pages that do not include a DOCTYPE and/or do not validate"

| Internet Explorer provides a way to identify itself that does not
| interfer with other browsers. Some web developers use this to work
| around bugs in IE's handling of style sheets or to import
| compability code. Other web developers regard this is an evil crutch.

The argument against Conditional Comments is not sound, at least not
for IE-specific workarounds. CCs are valid SGML markup.


I agree. I worked very hard on my wording to remain as neutral as
possible, I'll have to find a way to phrase "Other web developers regard
this is an evil crutch -- but they are wrong" a little more gently.

PointedEars

Thank you for your advice. There are a handful of people whom I had hoped
would take time to respond because I recognize their knowledge and skill
greatly exceeded my own. You are one of them.

Not to say others aren't welcome to respond. Other beginners, no doubt,
have their own lessons we can learn from.

I'll try to update that page later on today, after I've had a chance to
think about some of the things mentioned so far.

.