Live data from Hacker News

Front End Development Guidelines

taitems.tumblr.com

1–10 of 51 posts

Re: Front End Development Guidelines

#4
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.

Re: Front End Development Guidelines

#5

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.

It's much more common practice in JavaScript. If you ever expect anyone else to have to deal with your code, it's nicer for them if you followed the conventions that most people are used to seeing.

Re: Front End Development Guidelines

#6

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.

I think it comes down to the readability and weight of the two, with underscore separated variables taking more horizontal space. But like same line braces, one persons readability is not the same as anothers.

EDIT: The other response is more accurate.

Re: Front End Development Guidelines

#7

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.

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.

Re: Front End Development Guidelines

#8
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.

Re: Front End Development Guidelines

#9
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.

Re: Front End Development Guidelines

#10
post #2

A deep link for those that want to skip my pre-amble: http://taitems.github.com/Front-End-Development-Guidelines/

thank you for this excellent submission and write up - you've now given me some great suggestions to tackle this week on my Web app.

THIS is why I hang out here. :) Kudos..

Post reply on HN