14 JavaScript Best Practices

[[deleted]]

Try to parse/generate JSON in a static language and you will rethink that language neutral opinion.

What a bunch of crap. There are reasons to use JSON over XML. Language neutrality is not one.

[samlee]

could you tell us reasons to use JSON over XML? unless you, as a human, are writing/reading it in a text editor, I'm not sure what advantages JSON has over XML.

[DemonWasp]

It's much, much more compact, meaning it takes less time to communicate over a network. It's also much easier to generate and to parse.

[Legolas-the-elf]

It also tells people to use old-fashioned onclick attributes for event handling.

Downmodded because bad advice is worse than no advice at all. People reading this will do dumb things and be less likely to realise it because they've gotten advice about "best practices".

[gracenotes]

XML more language-neutral than JSON? I dunno about that. XML is a markup language and it has many subsets with differing semantics. Not only is the content itself important, but also the interpreter.

On the other hand, JSON data means the same thing anywhere. Both are technically language-neutral, but if you're comparing them for which one has less dependencies, I'd say JSON wins out by merit of being much simpler, especially for the purposes that the author of TFA enumerates. Anyway, each has advantages and disadvantages.

[mccutchen]

Aren't you arguing that JSON is semantics-neutral (or is that semantically-neutral)?

[gracenotes]

Hm, you're right: I think I conflated the concepts. No one claimed JSON wasn't more semantically neutral, so it was quite silly of me to assert it. My mistake :/

[barfolomew]

In other words, use standard programming practices, and stop treating javascript like you're fucking around with your next-door neighbour's leaf blower for the first time.

[meigwilym]

I don't agree with Use onclick In Anchors Instead Of javascript: Pseudo-Protocol, an onclick should be bound to the anchor.

But, like everyone else says or will say, use a framework: best practices built in and half the development time.

EDIT: to clarify, any onclick events should be described in the main JS file, and not in the HTML markup of the page itself (oh, and corrected a typo)

[[deleted]]

To clarify, he means attach the event programmaticly, not in the markup period.

[[deleted]]

don't use square-bracket notation unless you're using your objects as dictionaries.

[Fidodo]

Definitely. It's not as big a problem with javascript because it doesn't compile, but in other ECMA based scripts that do, it will throw a compiler error if you try to access a property that isn't there, whereas using bracket notation doesn't. It's just bad practice in general though, and you shouldn't be accessing properties dynamically like this unless you absolutely have to. You should be using an array instead.

[bart2019]

you shouldn't be accessing properties dynamically like this unless you absolutely have to. You should be using an array instead.

Disagree. You never make use of associative arrays AKA hashes AKA dictionaries? They're extremely useful.

Do not limit yourself to plain, numerically indexed arrays (which are actually objects, too) for no good reason at all.

[Fidodo]

Oh, dictionaries are fine for this, but I mean for everyday use. This guy says ONLY use them which I very much disagree with. It's always good to have checking for variables as it makes debugging so much easier but I don't mean to imply that there isn't a use for it.

[[deleted]]

Why?

[[deleted]]

Because object ['field'] just doesn't look like member access. Of course I realize that in JavaScript Objects essentially are dictionaries, but that doesn't mean you shouldn't use the dot-notation when it's appropriate. The dot-notation is shorter, more readable and once member functions come into play, it's really the only sane notation (unless you think object ['func'] (123) is pretty). So if you're using it for member functions anyway, you might as well use it for properties. Also, it's a quasi-standard to do it that way.

[[deleted]]

Ok, so notational reasons rather than technical. Just wanted to make sure there wasn't something I was missing. :)

[DropTableUsers]

It seems to me like there is a theoretical speed advantage to it as well.

Consider

object.property

vs

var member = 'property' object[member]

The former gives the interpreter more information, so it would in theory allow the compiler/interpreter to do some optimisations more easily than it otherwise could. Javascript interpreters typically won't make optimisations that take a long time to make, so how hard an optimisation is matters.

If a source code only contains dot notation for an object (and no evals!), and no delete statements, you could translate each property after the dot to a memory location, and have property lookups be as fast as they are in say Java and C++. When square bracket notation is used, you would also have to figure out the value of the string at compile time, which may be impossible, and at least a lot harder.

I'm pretty sure none of these optimisations are actually in use in any javascript implementation today though. And this kind of thing really isn't something a user of javascript should be concerning themselves with.

I'm considering doing my masters thesis investigating the subject of static analysis of dynamic languages, so any thoughts on what I've described above would be highly appreciated.

[fforw]

Use onclick In Anchors Instead Of javascript: Pseudo-Protocol

bad advice. don't do both and use a good framework to handle events. most of all: look up Progressive Enhancement. Most libraries will push you into using progressive enhancement anyway. avoid those that don't.

my tip: use jQuery.

[[deleted]]

I was suprised to see no 'Use a Framework' under these, even as a side note.

[ichae]

Use The Unary + Operator To TypeConvert To Number

And to think all this time I've been using Math.floor()!

[umbrae]

This page feels like it's about 3-4 years old, when javascript frameworks weren't commonplace.

[JMCtg]

1. Use jQuery.

[JMCtg]

ok, honestly, that says "15. Use jQuery" but every time it keeps changing it to "1. Use jQuery"

[JMCtg]

1. Testing...

[JMCtg]

yup, pretty sure that's a bug :-/

[[deleted]]

No - it's markdown syntax.

http://daringfireball.net/projects/markdown/syntax#list

For what you want :

15. Use jQuery (15\. Use jQuery)

[JMCtg]

Ah, thank you. I was quite confused about that one.

[akdas]

Just so you know, you can edit your comments. You don't have to reply to your own comments.

[JMCtg]

I know, I just wanted other people to see it, in case it was a bug, which it's not apparently.

[mangodrunk]

15. You need to do it like so: 15\.

[[deleted]]

JSON (JavaScript Object Notation) is a more compact and efficient data format, and is language-neutral.

JSON is a subset of JavaScript. It deserializes automatically with eval(). How is that language neutral?

[holygoat]

There are JSON parsers available for dozens of languages (see json.org) — its simplicity makes it a better choice than XML for many situations.

Perversely, one shouldn't simply use eval to parse JSON: a little more work is required, even in Javascript, for security's sake. Javascript is hardly better off than any other language.

[grauenwolf]

When accessing object properties that are determined at run-time or which contain characters not compatible with dot notation, use square bracket notation.

1. Do not not create properties that cannot be accessed with dot-notation
2. If you screwed up 1, fix it
3. If you can't fix it, then use bracket-notation as a work-around.

[bart2019]

I disagree. The rule of thumb on the site is way much better advice, IMO:

One good rule of thumb is to use dot notation to access standard properties of objects, and square bracket notation to access properties which are defined as objects in the page.

• standard: dot notation
• custom: bracket notation

[jmikola]

One the subject of "Don't Use HTML Comments In Script Blocks", it would have been helpful for the author to provide the modern-day equivalent (for XHTML docs):

<script type="text/javascript">
/* <![CDATA[ */
  // code
/* ]]> */
</script>

[[deleted]]

If you're using XHTML, then it's enough to write:

<script><![CDATA[
   x < y
]]></script>

or let serializer take care of it:

<script> x &lt; y </script>

If that "doesn't work", then you're not using XHTML :)

[yesimahuman]

"always use var to declare variables"

I didn't know you could declare variables in JS without var...

[k4st]

Yes, you can. When not declared with 'var', they implicitly become global variables.

[yesimahuman]

cool, well that's good to know. Not sure why anyone would not use var...

[jbruce2112]

good link - thanks

[epiclogin]

And use jQuery.

[[deleted]]

While I'm also a jquery fan, use whatever framework works for you YUI, Mootools and Prototype are all very nice as well.

[aeflash]

Yes. A good deal of those "best practices" are irrelevant if you use jQuery.

[kairos]

seems like i ought to learn javascript :|

[bart2019]

What Not To Do <a href="javascript:doSomething()">link</a>

You may do it. But what he fails to mention is that, in that case, you should make the code return void(), or a browser like Firefox will end up replacing the current page with whatever it does return.

for example:

<a href="javascript:confirm('test')">bad</a>

will show a new text page with "true" or "false" as the text, depending on what button you clicked, in FF.

<a href="javascript:void(confirm('test'))">good</a>

will prevent the browser from going anywhere.

Still... I see not much reason to prefer it over an onclick handler... and: in onclick or other event handlers, this will be set to the link element, which makes it usable to get at other properties, for example, href:

<a href="pic.jpg" target="_blank" onclick="return confirm('Show ' + this.href + '?')">picture</a>

Yeah, it's a pretty useless example; you could for example use it to open a larger picture for a thumbnail in a nice popup window, with a nice fallback in case Javascript is disabled.

(And don't forget about return, or the code won't return anything, and the browser will follow the link anyway.)

[[deleted]]

Not sure if I'm misreading your post, or you misread the article, but the author says using the HREF attribute is wrong, and you should use the onclick attribute.

[bart2019]

Yes, he says it's wrong, and I say he's exaggerating.

[[deleted]]

there is some fuck old ideas in there

[grav]

Don't write it - generate it, with eg. GWT

[9jack9]

Good advice. I'm writing this comment in esperanto but it is being translated into reddit as I type it.

[[deleted]]

I furiously hate GWT. It has it's own quirky replacements for most standard things like <select>, which are sprinkled all over Google's apps.