
Front End Development Guidelines - taitems
http://taitems.tumblr.com/post/5213581396/my-role-with-my-last-employer-involved-creating
======
fuzionmonkey
I disagree on the usage of double quotes over single quotes for strings.
Single quotes are useful when the string contains HTML.

The Google JavaScript Style guide recommends single quotes over double quotes
for this reason:

[http://google-
styleguide.googlecode.com/svn/trunk/javascript...](http://google-
styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Strings#Strings)

~~~
taitems
It's interesting that Google and jQuery seem to disagree on this as per:
<http://docs.jquery.com/JQuery_Core_Style_Guidelines#Strings>

I'm yet to see a compelling argument for either. My original paragraph for
string creation forgave C style strings, as they do seem very clean cut and
easy to identify. I think this is an area that needs some debate.

~~~
fuzionmonkey
I think the idea is that if you use single quotes for strings, you don't have
to escape the double quotes that are often found in html. '<p
id="foo">something</p>'

But the same goes for something like "you can't do that"

I guess it just depends what you don't want to escape. For Google, the more
probable scenario was probably the former.

~~~
julian37
The former isn't a very good reason: HTML/XML accept both double and single
quotes, so "<p id='foo'>something</p>" would work equally well.

~~~
joshontheweb
yes, but it is much more common for double quotes to be used in html

------
evanwalsh
"Javascript code requires regular commenting in order to make it easily
understandable."

Or you could, you know, just make code that's understandable.

I'm such an Internet jerk.

~~~
thaumaturgy
I usually aim to make code that solves the problem it was intended to solve,
as elegantly as possible. (Where elegance correlates closely to efficiency.)
Whether it's _understandable_ or not is completely secondary.

Often this means that if I don't leave myself a reasonable comment about what
I'm doing in that spot and why, I'll relearn the importance of good comments
later.

~~~
mattmanser
What you're describing is often considered to be bad code, not good code.

Maintainability is quite often the most important thing when it comes to
coding not terseness (which many do not consider to be elegant at all, quite
the opposite, they see it as unnecessarily complicated and obtuse).

------
pixeloution
Why do you believe camelCaseIsBetter and more readable then
using_underscores_in_variables ? While you're entitled to your opinion,
calling one "good" and the other "bad" is a bit overboard.

~~~
mileszs
I've been trying to follow the "do what is typical in the language in which
you're writing" philosophy. So, in Ruby, I use underscores, because most
methods and variables in common Ruby libs use underscores. In Javascript, I
use camel-case, for the same reason. In CSS, I use a dash. In PHP, I do
whatever tickles my fancy at that moment in time.

~~~
akavlie
My thoughts exactly. Much as I prefer the Python/Ruby convention of
underscores, this is not the JS convention, and consistency is important.

------
warfangle
I'd like to point out that if jQuery fell back to the fundamental
Array.prototype.forEach function when available, $.each would be /much/ faster
than a for loop. Array.prototype.forEach, when available, is native code.

~~~
timdown
No. forEach() being native doesn't prevent it from generally being slower than
a foor loop, because it still has to do a function call on every iteration.

~~~
warfangle
It depends on what you're doing within the loop. With a for loop, you still
have to perform an array lookup. For something simple, like summing up all the
numbers in an array, forEach is definitely faster. Try JSLitmus'ing it.

------
taitems
A deep link for those that want to skip my pre-amble:

<http://taitems.github.com/Front-End-Development-Guidelines/>

~~~
colinr
Sorry to point this out, but doesn't your section "@font-face Use and Abuse"
rule out embedding typefaces like Gotham?

~~~
taitems
Yep, I swapped it out at the last second. The previous typeface allowed
embedding without OTF and TTF. Someone raised the issue over Twitter and it is
now being tracked on GitHub.

------
codedivine
Aah, I went there expecting guidelines for building a lexer and a parser. Then
I realized this wasn't about a compiler frontend.

------
timdown
Generally not bad, but there are some errors and oversights in here:

\- At the end of the "Always Use === Comparison" section, the example will
throw a ReferenceError if (as is suggested) the variable `bar` has not been
declared. If you're testing a variable that may not have been declared, you
either need to use a `typeof` check or declare bar using `var bar;`, which
will be essentially a no-op if bar exists and declares it with a value of
`undefined` otherwise.

\- The comments example is demonstrating unnecessary comments. The check and
the call in

if (zeroAsAString === 0) { doHeapsOfStuff(param1, param2) }

... are self-explanatory to even the an inexperienced developer and do not
require comment. What may require comment is _why_ the code performs this
check and this call.

\- Your array in the "Loop Performance - Use ‘break;’ & ‘continue;’" section
has one element. I know it's just an example, but it would be better as an
example if it worked. You could instead use

var bigArray = new Array(1000);

\- Chaining has downsides, the main one being it makes debugging much harder.
You might want to mention this.

------
bialecki
This is good, but some of the advice isn't quite right. For instance "self" is
a reserved keyword in JavaScript, so often people use "_self" instead. And
camel casing variable names is right, unless they're constants, in which case
"THIS_IS_A_CONSTANT" is more appropriate. Too nit picky?

~~~
M1573RMU74710N
> camel casing variable names is right,

Personally I disagree. In my code-bases it's:

functions: doSomeThing()

constructor: new Foobar()

object/array/primitive: some_object

"constants": SOME_VALUE

I find that much more readable, especially when looking at code completion in
the IDE, I can always tell whether a property is a method or not.

For example, you might have an object foo that has a property called isBar. I
like being able to tell that that is a function that returns a true or false
value, as opposed to is_bar which just holds the boolean value.

------
zmmmmm
Nice guide & nicely written!

This example snippet actually generates a Javascript error (at least, in IE9):

    
    
        var foo = null;
     
        // foo is null, but bar is undefined as it has not been declared
        if (foo == null && bar == null) {
            // still got in here
        }
    

It will work if _bar_ is _declared_ but has value _undefined_ , but not if
_bar_ is completely undeclared as shown.

~~~
ricardobeat
common error.

    
    
      typeof bar === 'undefined'

------
asolove
These are good, I am pondering how to add to them. I think I would like to
start with a principles section. It is at least possible these days to get a
"principles of CS" education. But the principles of front-end are somewhat
different.

1\. This is the web. Users will resize the window, copy and paste, click a
button five times, turn off JavaScript, and arrive from every possible
combination of browser, operating system, and language. You will maintain an
appropriate fear of any trick so complicated that you don't know what it will
do under all of those circumstances.

2\. The user is always right. Even when they run unpatched IE7 with JavaScript
and CSS on but images hidden.

Then a few pointers I would like to add:

\- Think twice before binding to every instance of an event. Are you looking
for a keydown, a mouse move, or a scroll? Throttle your function to make sure
it runs only ten times a second, or whatever is appropriate. Ironically, the
faster browsers and JS environments become, the slower your pages will be if
you calculate something on all 1000 scroll events per second.

\- For heaven's sake try to avoid absolutely positioning your whole interface.
But if you do, you better try it in every browser and resize it real fast to
see if it works.

------
jgv
Kind of surprised that there's no love for sass/scss here. Scss has made
producing css a delight and v3.1 was just released which is great. Any front
end developer who hasn't given it a shot should try it at least once.

~~~
zerok
Indeed. But perhaps the author can't decide or doesn't want to recommend SASS
over LESS and vice versa.

------
geuis
Its better to link directly to the source, not a blog.
<http://taitems.github.com/Front-End-Development-Guidelines/>

~~~
taitems
I did that below as the first comment.

I was keen to write a foreword explaining that I am self-taught, so there are
going to be shortcomings in my theory knowledge - as I never did a CS degree.
It was to mitigate the shread-tearing I expected to receive in the comments
section of HN ;)

------
joshontheweb
I remember awhile back another post kinda like this where it was a companies
new front end dev training material. Anyone remember that or have a link? I've
been trying to find it.

~~~
julien_p
Not sure if this is what you're looking for, but it covers very similar
material <http://na.isobar.com/standards/>

~~~
joshontheweb
Im not sure if this is the one or not, but definitely a great resource and
more or less what I was looking for, thanks.

------
hartror
I find _Avoid Comparing to true and false_ a little pedantic and can someone
explain how it is "... bad as it's ambiguous"?

~~~
taitems
I'll put my hand up for that mistake. I think the word I was looking for was
"redundant", and not "ambiguous". Following the other concept of prefixing
your booleans with "can" "has" and "is", your variable names should be self
explanatory.

if (isSelectable === true) { ... }

versus:

if (isSelectable) { ... }

It's a shorthand method, similar to why you would use int++; instead of int =
int + 1;

~~~
joeyespo
I was just wondering the same thing. Thought there was some magic javascript
concept I somehow missed. Glad you answered!

Good article, bookmarked it for reference/a checklist.

------
Painbird
This looks good - however some of the language used is a bit interesting. I
laughed when I read "chain like a sick bitch" but I believe most people
(especially young kids, who will benefit from this the most) may see it as a
bit aggressive / over the top.

~~~
pbreit
I was a little off-put by the inclusion of that phrase.

