Why the rampant fanboyism around CoffeeScript worries me

note: this is a work in progress only 2/3 done. More to come soon!

It is good! We are saved!

Since 2009 when the world was introduced to CoffeeScript it has steadily gained momentum and in recent months its starting to seem like its become the inevitable progression from current day JavaScript to “the future is here” language of the Gods. By the title of my post you can probably guess I’m, shall we say, dubious of all the sappy love poems that are being written about CoffeeScript. I had been at first interested, then trepidatious and now at times almost seething about all the hype and yes rampant fanboyism growing around CoffeeScript.

But why? Why must I be the lone grump at the party?

That’s what this whole epic post is about so let me first say I’m not trying to be a troll here. I actually have some serious points to make and the first one is we should rightly give huge recognition to Jeremy Ashkenas, CoffeeScript IS a thing of beauty. It works, its a whole new language and yet it compiles down to plain old JS and it lets us try out some cool new language features and syntax, awesome right? And most importantly it is helping many programers love what they do and yes be productive. Even the royalty of JavaScript have nothing but praise: the God/Creator of JavaScript Brendan Eich had this to say when sharing the stage with Jeremy at this years JS Conf in Portland.

“It helps to have things like CoffeeScript out there it isn’t overriding, it doesn’t tell us what we must do but its suggestive, and if we want to pave that cow path we can, and I’m in favor.”

Or how about my personal idol, Doug Crockford when asked about CoffeeScript after his excellent talk on code style at this years TXJS conference in Austin.

“I think CoffeeScript is clearly good stuff. CoffeeScript is elegant it sort of takes the good parts, removes all of the stupid awful syntax that were inherited from the wrong languages, replaces it with something that is small and elegant and expressive. CoffeeScript is really great. And CoffeeScript is having a big influence on the ECMA Script committee….. CoffeeScript is definitely in the right direction and I would like to see future languages looking more like CoffeeScript than like C.”

So what do I really think? I think CoffeeScript’s big selling point of increased productivity is completely bogus because it optimizes for typing fewer characters vs readability when it should do the opposite.

Don’t be that guy

Clearly I had better be careful, I’m treading on very thin ice here… but I can’t hold it back any longer to be totally honest. I hate this designer language bullshit. Ahhh that feels better. Damn I thought this wasn’t about hating, but there I said it. It really is nothing personal against all the people that love CoffeeScript, but I get the feeling that CoffeeScript is just some hipster code for people that like the idea of being great programmers and super efficient at what they do but really don’t have the need for it. But that’s just one jerk’s opinion so go on loving it and using it for all I care.

OK now that I’ve purged the demons lets discuss the actual arguments I have. You may be surprised to note that, in fact, there are many common criticisms of CS that I’m going to skip right over. I have no intention of retreading the old complaints of the “leaky abstraction” argument, or the “compile step is a pain” argument, or the “debugging is a pain” argument, or the “output JS is less than perfect” argument. These complaints, weather valid or not, do not concern me. Moreover this post really isn’t about CoffeeScript at all, it goes way deeper than that. Its about the influence of CoffeeScript on the JS community and the direction of the ECMA Script standard itself. So here are my three arguments.

If you didn’t catch that, what I’m saying is that the following is not attempting to be a CoffeeScript hit-piece its about the direction of JavaScript. 

  1. Stripping characters from the syntax is a false solution to increased productivity
  2. Overly terse syntax can make code harder to scan and understand.
  3. JavaScript as a compile target weakens and fragments the community

Ultimately I think the ongoing pursuit of a more perfect programming language is a noble one. Despite the good intentions there are some very disheartening tendencies I see coming out of the ECMA Script standards body and I don’t want to see the language spec itself turned into a dumping ground for “whats hot now in language design.” Broad assumptions about productivity and what the JS community need and want are being made in ECMA Script discussions for the next JS veriosn after ES5. This is where I start to get seriously concerned. So lets address this head on.

What really matters here anyway?

Ultimately the best thing about JavaScript is its amazing community but I’m concerned its getting distracted trying to fix things that are not broken with shiny new syntax and cute language features. (yeah I know you’ll mention all the bad parts of JS now) It feels like all so much newness for newness sake. Rather than diddle with our keywords and curly braces I’d rather see the JS community focus on solving real world problems through the power of our code and our collaborative energies. Lets quickly peek at an example of what I’m talking about, shall we. Take a look at the Github profiles of LearnBoost and its employees. If you know anything about the node.js community then you’ll agree these guys are titans. In particular check out visionmedia (TJ Holowaychuk) a new idol of mine. TJ is a machine! Ask yourself if your organization has been as productive as LearnBoost or if you’ve created 1% of the value that TJ has for the js community and his company. I guarantee whatever the percentage you come up with is, futzing around with the language is not going to make it go up. Note: as far as I can tell TJ is a pretty big CoffeeScript skeptic as well.

Lets unpack our assumptions that are propping up the strong emotions we have around some feature or syntax. Ultimately all this is about being more productive so lets find the best way forward for this conversation that puts the focus where it needs to be. Helping developers ship good code often. (Just a preview: Surprise, surprise, the language and its syntax are not key factors here.)

But Maybe I’m Wrong

Perhaps in a few short years, or months at this rate, someone will come by this blog post (yeah right Ive had all of 5 visitors) and think “ohh how quaint, there once was a day when lesser programmers thought so highly of their decrepit old ways as to question the perfection that is CoffeeScript which has freed humanity from toil and is clearly right and good. Praise be to Eich, Amen.”

Well I guess I’ll just have to be that guy then. I just hope I don’t sound like I’m trying to sell and old outmoded technology like this dude.

Check yo self

Before I get to the three arguments lets first do a little meta-cognition just to check ourselves. We should always be the first ones to point out our own foibles. By always reminding ourselves how we commonly stray from sound reasoning we can hopefully, more often than not, catch ourselves in the act. This is also for those who would suggest that I’m being ignorant or biased in some way that in fact I’m actually trying really hard not to be. Here are three points I have seriously considered over the past week while I’ve been writing this.

First Head Check: - This study found people have a bias to truly creative ideas. The studies’ findings include:

  • Creative ideas are by definition novel, and novelty can trigger feelings of uncertainty that make most people uncomfortable.
  • People dismiss creative ideas in favor of ideas that are purely practical — tried and true.
  • Objective evidence shoring up the validity of a creative proposal does not motivate people to accept it.
  • Anti-creativity bias is so subtle that people are unaware of it, which can interfere with their ability to recognize a creative idea.
So clearly by this point it looks like I’m just biased to a truly creative, new idea. But I would argue that this is not whats upsetting me. Read on.

Second Head Check - Programmers love the language they know and everything else sucks.

Programmers have peculiar, near-religious emotions about programming language preferences. There is a constant battle between programmers of all stripes and the arguments are all over the board. “This language is better than that because of x, y, z.” “Here are ten reasons why your language sucks.” Etc. Etc. In one of his talks I recall Douglas Crockford bringing some great perspective to this incessant fracas. Sorry I can’t find the specific video so I’ll summarize.
  • Moore’s Law means doubling in performance every 2 years or so.
  • Software is not ruled by Moore’s Law, its ruled by Murphy’s Law.
  • We see leaps in software performance in roughly 20 year increments.
  • Part of this is due to the generational nature of language preference.
  • Programmers (and everyone else) are biased to what they know and love and reject new ideas (see first head check).
  • So it takes a whole new generation of programmers to legitimize a new language.  A generation that is not encumbered by prejudice and preference of an old inferior language.
I could simply be falling into this nasty trap. JavaScript is my favorite language for well over a decade. Its what I think about all day, its what I dream in. That makes me all the more likely to defend it out of emotion rather than reason. But although I’ll recognize that I do have strong emotions about this matter I assure you they are because of objective reasoning about productivity. There’s far more to meaningful productivity gains to be had in this world than what you could maybe get from some new language-feature soup in a stripped down syntax.

Third Head Check- We all want to feel like we are in control and know what is best.

Have you ever worked with that manager or colleague or fellow student that just had to take ownership of everything? You show them something great and new and they have to start hating it right away and put their little fingerprint on it before its good enough. And by fingerprint I mean repeated blows from a sledge hammer. People like this are roadblocks to innovation and getting good work done efficiently. They must feel threatened, disrespected for not being consulted, and from their perspective their valuable knowledge and skills are needed. Ultimately they get their way, preventing change for a multitude of off the wall reasons. They get their way or else there’s high drama and who has time for that? So now innovation has been stifled (or in their minds a fire has been put out) and hey they feel better and “now we can ship!”

Could that be me? God I hope not, those people are really annoying. But resistance to change is natural. If things changed all the time we would just be stuck in perpetual adjustment to the new conditions. And sometimes lack of change is a very good thing. (some people call it stability) One of the best things to happen to JavaScript was the dominance of Microsoft in the browser-wars and the following half decade of nearly zero innovation from them. It left the stage ripe for a dusty and ignored technology, XML HTTP requests, to herald in a new age of software on the web. But we should be farther ahead by now and yet we’re still futzing around with essentially the same web 2.0 widgets. Take a close look. The drastic changes in syntax CoffeeScript brings to the table looks like mere chipping at the edges when you think about what really needs to change to give us the next 20 year cycle of software innovation. Douglas Crockford argues its about distributed computing with the Actor Model and a stronger security framework. I totally agree about the need for better security and better distributed computing. I don’t care how terse your syntax is, its not going to have an effect on these problems.

So head checks complete, lets (finally) get right into the arguments

First Argument: Stripping characters from the syntax is a false solution to increased productivity.

In fact my second argument below is that removing the characters makes the code harder to scan and quickly understand, thus making you less efficient. But lets look at this whole myth of “terse code is more productive because you have to type less.” When did this motive arise in the JS community? I have noticed in a few older videos Douglas Crockford and Brendan Eich asking the audience what they would like to replace the function keyword with. “how about the florin?” Doug asks for people to raise hands. He gets few bites on his various ideas and then relents and asks “no change?” This elicits a big response. What the hell? Where did this crap come from. When did anyone ever have a problem with typing the word function? And now they want to use -> instead because its soo much shorter. Well haaang on there. It jsut so happens that typing “function” is not very hard to do. In fact most IDEs will auto-complete it for you. And yet this is a big deal in the new Harmony discussions? Heres Brendan talking again from the JSConf video I liked to above.

“On more thing that I think I have to talk about because I talk about it at every talk I give which is function syntax. Im still paying for usings 8 letter key words in 1995 I think I took it from awk and ahh heh I shoudnt have done that, I should have used fn and we would have been past this becasue probably two letters is short enough. Um and were using fn in rust at mozilla. But its hard to change and the idea that you would use of a greek lamda which is an actual unicode identifier allowed in ES3 and ES5 or the florin which Doug Crockford suggested but didnt really champion, those don’t really ring true. Then there was a proposal to use hash but I think we want hash for something else and I have kind of come to realize, to be very frank, that CoffeScript has already done the right thing, C# has done this. So I am proposing for the next ECMA Script meeting, and wish me luck becasue it is not a sure thing, that we just standardize this. That what people really want is very sweet short function syntax without that leading key-word and the arrow form in CoffeScript gives us that…”

And then theres this gem.

“It matters becasue keystrokes matter and you see this over time you see people gravitating to lighter syntax you see productivity mattering in the long run even if it is a small win.”

I have a question for every single group of product developers that have a great idea about “what people really want.”

Hey Brendan Eich, I’M TALKING TO YOU

My question is can you prove it? I have a very strong suspicion that of course you can’t prove it. You have two crappy languages that use it and thats enough of an excuse? All to do what? Scratch an itch youve had for a long time to make the language more terse to save on 6 keystrokes? There are actually valuable scanability and readability benefits to having the whole word there my friend and the fact that a vocal minority and a few language dictators such as yourself on the ECMA TC39 panel have a Jones to shorten the function keyword into an obtuse abstraction is a hairs breath away from changing the dot operator to do concat like in php or something stupid like that. THERE IS NO FREAKING REASON TO DO IT. You have given no real reason, just the off hand remark implying (and I paraphrase) “of course its obvious that EVERYONE wants this because it will make us all SOOO much more PRODUCTIVE.” Admit it Brendan you can never give a good reason for switching function to -> let alone one that would warrant changing the worlds most popular and widely used programming language to be less readable. This is because there is no good reason. Its just your language-designer tastes that are waaaay too, well, designer. You’re picking out the European orange leather couches and all we want is the damn roof to stop leaking and the foundation shored up.

In your own blog you call for dialogue intend to listen to the JavaScript community and its “natural leaders”

“JS developers and implementors on TC39 must learn from one another and “meet in the middle”. The Harmony goals are good. But developers may do only what can be done in library code, or reach for CoffeeScript or another language on top of JS. And TC39 may over-invent.

The better way is a dialog between JS developers, especially natural leaders among them such as @jashkenas, and TC39 members.”

How convenient, it must simply by a wonderful coincidence that you happen to be promoting CoffeScript style syntax and Jeremy Ashkenas makes your short list of “natural leaders” in the JavaScript community. I wonder what the jQuery team thinks about all your proposals, or what the node.js committers think about your proposals or what other (I would argue) greater leaders in the js community think about changing the function key word or paren-less syntax. Well have you asked them? I think you already know and are only hilighting the person that agrees with you the most.

OK im done ranting at invisible Brendan Eich now (as if hes going to read this) :-)

Edit: the “invisible” comment was not trying to make Brendan out to be an absente landlord of the language, in fact he is extremely open and available and should be commended for being so.

I am not the only one that is concerned about the direction of JS with all the new Harmoy proposals and the things that are being pushing beyond that. I think I have some bakckup on this in the form of Ryan Dahl. If there is anything like a natural leader in the JS community he is certainly one of the most influential right now. And he counts one of the most vital portions of the JS community as his army. So i was very heartened when Ryan Dahl ripped into the ECMA Scipt committee at node conf.

“I wish ECMA Script woudnt be so ahhh “fancy pants” about adding all these features. We need 64 bit integers, please do that first. Then think about proxies in like ten years or like after we’re all dead. (applause) JavaScript does not need more features it just needs a couple of small things fixed.”

Thankfully Brendan was sitting in the audience for this very panel discussion and eventually got up on stage himself to address the matter.

“Everey tool has edges you need to smooth out so theres more work to do on JavaScript usability. When you look at how its used in Node its a bit different than how its used in the browser. Theres some overloap but looking at Node makes me think more about binary data and even 64 bit ints. It makes me think more about um.. getting rid of the spaghetti monster. The client has solved that a long time ago and it doesnt nest as deep I think, the logic doesnt chain as deep.”

Ok it sounds like Brendan Eich can come around to logic and reason. Cool.  We’ve established why they seem so hard up to change syntax, they assert with no evidence that everyone wants it and that it makes us more productive to type less. You’ve got my feelings on the whole everyone wants this BS. Lets address the really important thing here. EVEN IF everyone wanted it, it would still be the wrong thing to do. That is because it will do nothing positive in the way of productivity if anything it will certainly reduce readability and thus lower productivity.

“So what is it that productivity stems from if not typing less?” I’m so glad you asked we can finally get to something actually important. (I told you we’d get here)

This is a very well studied subject matter. But we needn’t go far for good insight, Douglas Crockford has a absolutely fantastic talk on code quality that really hammers it home.

“Programmers don’t understand how they spend their time. They think its mostly typing programs. Mostly they are having technical conversations with collegues or in meetings or staring at the screen puzzeling over the code and problems they have to deal with.

Programmers tend to be skeptical of process improvements that might require more keystrokes.

I turns out that programmers really arent spending much time typing their software. But thats where we look for stuff, “I want an IDE with autocomple so I don’t have to type so much, I’ll go so much faster that’ll really improve my productivity.” I think those particular improvement in productivity are negligible. That’s not where the time is being spent. Programming is now a social activity.

The simplest thing we can do to enhance the value of our codebase is to make our programs more readable. Our ability to read our programs is the thing what gives the codebase value.”

Amen to that!

Updates:

On Harmony syntax changes: I had a short twitter conversation with Brendan Eich and he made it clear that although he wants -> function syntax it is not making its way into Harmony.

On feedback: So at this point in the process I thought I’d air out what I had so far by posting on the node.js mailing list. Interestingly enough Jeremy Ashkenas caught wind of this article and posted my rant on Hacker News. From the comments I’ve been getting most people disagree with me, several making good arguments. This was by far the funniest comment on HN by TrevorBurnham “…made me wonder momentarily if the essay was a work of post-modern art, subversively advertising the benefits of CoffeeScript through an implausible flourish of logorrhoea. If so: Well done, sir.” Ouch! Well what can I say it’s a hasty rant that became a big blog post. I don’t claim to be a language designer or a professional tech blogger. Im just one opinionated jerk that is apparently woefully wrongheadded about this subject. Well lets get this over with shall we.

 Second Argument: Overly terse syntax can make code harder to scan and understand.

“What?” You are probably crying out in wild eyed disbelief. “How can it be harder to read if it has fewer characters.” I know what you’re thinking. “It conveys the same data in a cleaner package so we can scan more code, see more of whats going on with less scrolling and fewer eye catching distractions like semicolons and curly braces. Its the epitome of readability!”

Well, some people call curly braces and parens “noise”, but I call them punctuation. I suppose you could consider punctuation marks in a book noise as well. I also think that the word “function” is a better signifier of a function than the more abstract tokens such as -> or #. Is all of this just a matter of subjevtive opinions, individualistic esthetic tastes? I think a large ammount of it is but there has to be something concrete that makes us wince at java or objective-c when compared to JavaScript. I think it is a matter of how easy or hard it is to quickly comprehend the problem and solution embodied in the code. Reading and understanding source code is one of the most important and time consuming activites that programmers perform. So we should optimize for readability.

The basic fact is that we can argue this until we are all blue in the face becasue we have no objective way to grade one language or another. Hence we have what seems to be a resonable if automatic, positive response to reductions in syntax. The assumption is that if one language is easier on the eyes as it strips away boilerplate and verbose syntax then it follows that another must be better as even more things get stripped away. Now, to be clear, I am speaking purely in terms of the visual effect of the language on our ability to comprehend the code as written. There is an unquestioned assumption that less syntax is, esentially, always better, with apparently no point of diminishing returns. This view implies that the visual nature of code is that it gets more readable as it gets more terse. Well, I’d like to question those assumptions. Because they imply the point of code is to take up as littel space as possible but thats bogus. I think the point of code is to enable people to clearly express and understand a range of complex computational processes. Hopefully that computational process is solving an actual problem and so it should help you understand the nature of the problem and the nature of the solution employed. Thats a lot of responsibility and I think the visual/spatial nature of code is essential to fully succeeding at that task.

I think some code will help express the point.

// #6 Filter list of numbers into two categories.
// from http://ricardo.cc/2011/06/02/10-CoffeeScript-One-Liners-to-Impress-Your-Friends.html
passed = []
failed = []
(if score > 60 then passed else failed).push score for score in [49, 58, 76, 82, 88, 90]

// roughly equivalent in js
var passed = [],
    failed = [];
[49, 58, 76, 82, 88, 90].forEach(function(score) {(score > 60 ? passed : failed).push(score)});

// or more verbose js with more visual/spatial structure
var passed = [],
    failed = [],
    score,
    scores = [49, 58, 76, 82, 88, 90],
    cutoff = 60,
    i = scores.length;

while (i--) {
    score = scores[i];
    if (score > cutoff) {
        passed.unshift(score);
    } else {
        failed.unshift(score);
    }
}

Of couse anyone can pick a piece of code to make a point about one language or another. So the above code is purely to express the concept that there can be meaningful spatial information present in code.

This is a murky subject but there is some research in the area. In my short research I did find some interesting papers that address the spatial nature of learning to program[1], code navigation[2], spatial cognition[3], code scanning patterns[4], and An Eye Tracking Study on camelCase and under_score Identifier Styles[5]. There is good evidence to correlate cognitive spatial capability with ability to learn programming.  There are common explanations of how programmers comprehend code. All of the papers refer to various concepts of building mental models that are spatial in nature.

There are also notions of Beacons which are…

“sets of key features that typically indicate the presence of a particular data structure or operation in source code… Meaningful variable and procedure names have been described as Beacons. The swap operation has been shown to be a Beacon and to be beneficial in comprehension as well. ” [4]

I have to concede that this is a purely academic discussion at this point. But it need not be. Language developers should seek methods of validating their theories and motivations as they develop the spec. The studies I cite point to some interesting avenues like gaze-tracking to get deeper insight into the process of reading code and building a mental model of it. This technique is really hot right now and I think it can have some value to language designers.

However much of this scientific approach to things sounds good but the results may be very context specific. It’s clear language design is very much and art and a science.

None-the-less I believe we need to improve our understanding of the visual effect of a language and its syntax on our ability to efficiently build a working, mental model of the program as we read the code. I’m self-trained in programming, my education is in, of all things, fine art and design. The design background serves me well in the world of web design. But part of it beacons to point out that the visual effect of code, indented, with its various syntax hilighted tokens exists every bit as much as a visual entity as a textual one. I think this aspect of code is well worth discussing and researching more. I have a colleague that meticulously picks the colors for his light on dark theme for intelliJ. Its a thing of beauty. I don’t think there is a developer out there that would argue the value of syntax hilighting. The colors obviously help us to see the structure of the code more clearly and thus build that mental model of what we’re dealing with. I argue that so too the effects of syntax and key-words by their very shape, and the visual patterns that emerge in a page of code, plays a similar role. It can help us to build an understanding of the code purely by means of visual cues.

A great way to test this theory for yourself is to spend some time reviewing code samples over at Rosetta Code.

The site exhibits solutions to specific problems in as many languages as possible. This is a fantastic resource to get a feel for the relative visual qualities of various languages. Look at the code as a visual structure, gaze at it and try to see the meaning of the code first with an eye toward the spatial relationships then by reading it intently. As you read it think of that mental model you’re trying to build of how the code works. Is the visual structure of the code doing you any favors or is it adding a layer of complexity to things. If the two reinforce each other I think that is a sign of a better piece of code. It will probably be easier to understand and maintain long after it is initially written. Now remember this is not purely about syntax, its about the visual quality of a piece of colorful, very structured text. Take a look at the csv to html translation problem on rosetta code.

This is a very strait-forward problem with a very simple solution. Go ahead and compare your favorite languages, the JavaScript example was submitted by yours truly :-) Its based it on the CoffeScript example with some modifications. Lets look at two samples.

So what criteria makes one solution more comprehendible, in less time, than another? Obviously familiarity with the language plays a huge role. You can clearly argue that lines of code and clean syntax have a fairly profound impact. But once you get beyond that I think other aspects become important as well. I think the visual/spatial characteristic of the code as it is written can make a meaningful impact our ability to chunk up a program’s logic and constituent parts into a working mental model of the software. Code is written for people not machines. If it were then we’d all be typing out binary or assembly. But as Doug Crockford says “we’re not trying to be E.E. Cummings here.”

Argument 3: JavaScript as a compile target weakens and fragments the community

introducing the asap js loader library

Here it is a very early version of asap on github

The overly creative readme.txt says it all. Reproduced here cus I don’t want to do any more typing.

————————————————————————————————————————————————————————————————-

Here at readme.txt we love finding out just who it is were reporting on, in that vein we sat down with asap.js on the 1st of April 2010 to delve deep into his unique predilection for loading javascript early and fast. Lets cut right the transcript.

RM: So is this a joke or what, it is April 1st?
ASAP: No. I really am a new js loader! I know its stupid right? We already have two great loaders in LABjs and RequireJS I would not be surprised if there are a ton more.

RM: Interesting, both of those js loaders were profiled on the hugely popular Ajaxian.com blog. Is this just a pathetic attempt to get on Ajaxian?
ASAP: YES! Well actually I only learned of LABjs after I was initially written as a little helper for my creator, furthermore I was birthed into a more functional version 0.2 on March 17th one day before the Ajaxian post on RequireJS. You can imagine how deflated I was in both instances… but alas here I am :-) Don’t hate me cus I’m beautiful.

RM: There, there… nobody hates you asap. Tell me more about yourself. What really turns you on?
ASAP: Well you need to include me in your page, in the head or the bottom of the page. I like being at the bottom personally. Then I’ll do all the rest of the work to load all your code and fire off the required init functions when the page and the code are ready.

RM: I’m looking at your source code here and it looks like you’ve implemented a cute little ajax get method, and your domReady event is basically the exact same thing jQuery uses?
ASAP: Well it may sound ironic but I didn’t want to reinvent the wheel. Heh, well it is nice to use my get method to load code in an asynchronous way. I’ll load it via AJAX if I can and build a script tag with it, otherwise I’ll load the js in a slower synchronous manner (setting the src on a dynamic script tag) for compatibility sake. Either way I’ll prevent the js from blocking other page resources from loading. Loading code as soon as possible while maintaining script eval order is what I do!
One last thing, the domReady event can be used but it is recommended that users pass thier callbacks into my codeReady method, that will fire after both domReady AND all the code is eval’d.

RM: Isnt it true that RequireJS can actually load code faster than you?
ASAP: Yes they have a good system but it I think you’re thinking of the feature that requires you to package your code ahead of time so that it doesn’t eval out of order, usually that code will be on your own server and in that case you can just use AJAX to load it anyway. So in that case I don’t think its any faster.

RM: I see you weigh in at a measly 5k when minified.
ASAP: Roughly, yes I’m a few bytes larger than LABjs and a few k smaller than RequireJS, but when I talk k’s I’m only talking AFAIK k’s. OK?

RM: Cool, whats next? Give us a taste of the real asap at work.
ASAP: OK here’s a couple code samples :-)

		//simple array notation syntax...

		asap.require([
			"js/libs/jquery-1.4.2.min.js",
			"js/simple.js"
		]).codeReady(function(){
			simple.init();
		});

		// object notation providing a local root

		asap.require({
			root: "http://www.mysite.com/",
			files: [
				"http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js",
				"js/simple.js"
			]
		}).codeReady(function(){
			simple.init();
		});

RM: Aren’t there problems with debugging code when its loaded with ajax, no line numbers?
ASAP: Good point, that’s why there are three ways you can force asap to use the slower dynamic script attachment method when you want to debug and get nice line numbers in your debug console.

The first two require you to edit the file, you can:
* pass a true boolian into the require call as the second parameter using any syntax or,
* you can add a debug property with a value of true in the object notation form

but my favorite way to jump into debug mode:
* add the param asap=debug to your url

RM: Looks good asap! Now if only Dion and Ben would would give you the time of day you might be forced to create some serious tests.
ASAP: Its true I need some robust tests to verify my code correctness and functionality across all platforms…. there is a reason I’m version 0.3.

End of interview…

Aaaaand that wraps it up for this edition of readme.txt check back again when we review yet another thing we came with.

Complete noob’s guide for budding web developers

So you wanna make websites huh?

Hmm that’s nice but web sites are soo over… its all about web applications these days. Whats the difference you ask? Well one is a program the other is a document. That said, its a great time to become a web developer, the skill set is becoming more valuable and important every day and if you’re a self starter the education is completely free for the taking.  But before you dive in ask yourself why you want to jump into the world of the web as yet one more of its makers, of which there are legion…. is it Fame? Fortune? The perks? Dreams of changing the world? Lets break it down…

Money? Well the money can be great if you’re good and it can be equally pathetic if you don’t find a niche or you’re slow to pick up the material. Like anything I suppose I wouldn’t buy into any advice that says its better or worse than any other profession like lawyer, nurse, architect, sales rep etc. I would also advise staying away if you don’t like staring at a computer all day or think you’ll get rich working from home 4 hrs a day.

Fame? Its available to some degree… lets face it you are most likely not going to become the creator of the next Facebook (and how famous is that guy anyway?) but there are always innovators and productive creators gaining admiration of their peers. That could be you too! That kind of community recognition is fun to strive for and certainly not out of reach.

Perks? What perks? The work can be mentally stimulating if you have a the mind for it, and it provides great opportunity for pretty wide open creativity. On the down side it can be very monotonous, tedious and down right infuriating. If anything you’ll become the go-to person for anyone you know for their web-centric ambitions. This can be a burden… before you start taking on such work you’ll have to learn how to  properly price your services to fend off the people with big ideas and meager budgets, or you could be in for serious frustration.

Changing the world? Well here we finally get to dig in deep don’t we? The web is pervasive, it touches so many lives and its quickly becoming the basis for all modern software. The web has become the playground, testing grounds and proving-grounds of modern user interfaces and complex, networked, multi-user applications. It has been so successful that the world has certainly been and is still under swift change because of it. The web as a platform is fertile ground for innovation… That said many argue that the web has reached its plateau in terms of true innovation and that the rest of the change we see happen on the web will be incremental not transformative. I don’t dispute that, however I would argue that there are plenty of problems that lie in wait to be solved in a more effective and efficient way, the trick is to find the problems that need solving and that has little do with coding web pages.

OK so that’s a pathetic review of a pretty broad concept… “web developer” is a catchall term, it encompass a whole professional sector, but nonetheless it is an intro.  So what am I talking about if not a whole professional sector? Specifically client-side web application development. The stuff that actually gets sent over the inter-tubes, loaded into your web browser and seen and used by the end user. That leads to a bevy of technologies,  many with acronyms…. HTML, PNG, CSS, Flash, AJAX, JavaScript. “Client” refers to the Client in the traditional Client-Server architecture of the web and specifically the web browser software is generally the client we most often deal with. Other clients could for example be widget platforms that use the same technologies as web browsers to create their interface ie. HTML, CSS, JS. Sorry to say however, you won’t get off that easy, to really do the work you’ll most likely need to familiarize yourself with the server end of things which brings in more programming and databases as well.

So now it looks like you’ll basically need to be a jack of all trades, a graphic designer, a copy writer (often overlooked), a programmer, and a database manager. You’ll need to know many different applications, many languages of different flavors, markup, scripting and programming. That, for the most-part, is true but you’ll eventually find out what you’re really good at and specialize in that. There are generally a couple directions to go, I generally think of them as “the design guru”, “the engineer”, and “the coder”.

The design guru is basically a graphic arts nut that would be just as happy designing magazine spreads, drawing comics or designing web sites . This is someone who brings their unique creative flair to the process of designing for the web. That generally means they spend most of thier time producing mock-ups in Photoshop and or Illustrator and turning them into HTML + CSS. The more experienced become proficient with JavaScript or Flash and know enough about the server end of things to modify a WordPress or Drupal template.

The engineer is someone who has pursued Computer Science as a career path, learned Java in school, is well versed in Object Oriented Programming and has focused on developing the “backend” of  web applications, the account management, database queries, serving up the content and processing data submitted from forms. They understand HTML, CSS and JavaScript but tend to look at it with derision as its a loose and messy jumble of technologies as compared to “real” programming. Update: I just read this and honestly that is how it used to be but now with the advent of real applications in the browser the code for things like Google maps and Docs require serious engineering skills. Point is, weather on the client in the form of JavaScript or on the server in the form of some other language, most of the effort is directed at advanced Object Oriented Programming.

The coder is someone who has their feet firmly planted in both the design and programming worlds finding a zen-like balance in every aspect of their work, “I could program this awesome new feature or just fake it with Photoshop and a couple CSS tricks… hmm.” Here the coder would debate the immediate time-savings of an effect vs. the beauty of  a programmatic solution that could be re-used. These are often challenging decisions to the coder because they embrace the yin and the yang.  The coder is skilled with Photoshop but cares little for Illustrator, knows Javascript and PHP front-words and back but avoids the world of Java for the most-part. These preferences stem from the coders need for expedience. They cover so much territory and must economize by learning one server-side language so they learn the most common. They don’t have time to pick up Illustrator and since Photoshop is ideal for creating web graphics and site mock-ups why bother?

So what kind of web developer do you think you will become?

Alright, enough chit-chat! Lets dive in and get prepared to start making this stuff.

Here’s an overview of what you’ll need.

  • A quick preview of what it is that were talking about
  • The confidence and ability to learn on your own
  • A firm grasp of the core concepts and all the software it implies
  • A collection of top notch resources
  • A good code editor
  • Photoshop
  • Familiarity with industry best practices
  • Knowledge of the pitfalls so you don’t fall into them

I will provide some details for each of the above as a starting point with a mind toward the coders middle way approach, throwing all aspects of the process from back-end to front-end, from code to design, all roughly at the same time. Insane you say? No, this is just the reality of it, you will always need to grow your skills incrementally all at once. If you don’t learn how to do that now you’ll have a much harder time in the future learning whatever new combination of technologies it will take to get your job done 5, 10, 15 years from now. Learning many integrated technologies all at once is in itself a key skill for the web developer and is exemplified by the coder’s middle way. May the force be with you young padawan learner.

First a quick preview

Before we get into more conceptual bits lets take a quick look at the actual subject matter in light-form, so we are all on the same page. Lets say we have some text and a few pictures we want to turn into a basic web page.

This is the text:

A view from above

Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble’s the observatory’s lifetime. Scientists hope to begin beaming back the results by early September.

Here are the pictures:



Lets see what the html looks like.

<html>
	<head>
		<title>A view from above</title>
	</head>
	<body>
		<h1>A view from above</h1>
		<p>Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble's the observatory's lifetime. Scientists hope to begin beaming back the results by early September. <a href="http://www.komonews.com/news/photos/45855337.html">Full article</a></p>
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20-150x150.jpg" />
	</body>
</html>

now load up the page to see how it renders.

OK now lets style it up a bit with some simple CSS.

/* remove browser default padding */
html, body, h1, p, img {
	padding: 0;
	margin: 0;
}

/* use a reversed color style with arial fonts */
body {
	background: #000;
	padding: 24px;
	font-family: arial, sans-serif;
	color: #ddd;
}

h1 {
	font-size: 24px;
	font-weight: bold;
	color: #fff;
	margin-bottom: 1em;
}

/* put the text in a box */
p {
	border: solid 1px #555;
	background: #333;
	padding: 1.5em;
	margin-bottom: 1.5em;
}

img {
	padding: 0;
	margin-right: 1.5em;
	margin-bottom: 1.5em;
	border: solid 1px #333;
}

The CSS can be written right into the page using a style tag but in this case I’ll save it as a separate file and add in a link to it by adding the following line to the head section of the HTML.


<link type="text/css" rel="stylesheet" href="simplepage2.css">

Take a look at the new page to see the CSS do its thing.

Lets make this page more interactive by adding in links to the high resolution versions. Ill do this by wrapping the images in “a” or anchor tags. These are the things we commonly call links. For this example we have to style the image links differently than the text links. To facilitate this we wrap the group of images in a div with an id, then in the CSS we can key off that id to style just those links.

<html>
	<head>
		<title>this is the title</title>
		<link type="text/css" rel="stylesheet" href="simplepage3.css">

	</head>
	<body>
		<h1>A view from above</h1>
		<p>Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble's the observatory's lifetime. Scientists hope to begin beaming back the results by early September. <a href="http://www.komonews.com/news/photos/45855337.html">Full article.</a></p>

		<div id="imageLinks">
			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20-150x150.jpg" />
			</a>
		</div>

	</body>
</html>

The css gets modified slightly the following code replaces the existing rule for img.

/*================= rules for the imageLinks section ==================*/
/*
 now that we have the images wraped in a div with the "imageLinks" id
 we can easily style just the elements within.
*/

#imageLinks a {
	/*
	 "a" is an "inline" element (treated like text) by default and images
	 are "block" element so for proper rendering of images as links we tell
	 the a to be like an image, not text, this also solves some rendering
	 oddities but we also have to float the images left so they line up
	 like before rather than stack on top of each other in a single column.
	*/
	display: block;
	float: left;

	/*
	 moved the margin here to the a instead of the img becasue the margins on
	 the img became clickable which was odd.
	*/
	margin-right: 1.5em;
	margin-bottom: 1.5em;
}

#imageLinks img {
	border: solid 1px #333;
}

Version three with links to high-res images.

This is a very simple web page but now you have an idea of what we’re dealing with.

The confidence and ability to learn on your own

Remember I said that the education was free… well that all depends on what type of learner you are and how good you are a finding the right materials. Trust me its out there and I’ll point you in the right directions but you’ll eventually have to be careful to avoid outdated or altogether bad advice. Buyer beware. Furthermore If you can’t thrive in this type of learning environment… by the seat of your pants, grab it off the web and try it right now… then I would question your interest in web development. The field changes so fast you have to learn new things this way, every day. Its key.

A firm grasp of the concepts and software, Ok here we go…

Think of the stack of technologies it takes to get a situation where a user can log into a site like Facebook. That stack begins with servers usually in a data-center managed remotely by Information Tech dudes. Those servers run some key software you’ll need to be familiar with, namely the Linux operating system running Apache HTTP server, MySQL server and PHP. This is the most common server configuration and it is often called the LAMP stack. Thankfully you can get the stack setup on your own computer for development and learning purposes with ease. On the mac go get MAMP in Windows go get XAMP. Note that I will not tell you how to set up software and configure it. RTFM. Look it up.

Get that installed and working and you have the server stuff done for now :-)

Next think about what you actually are looking at in a web browser, pictures, text, links, a page that has some sort of layout and design to it. It all gets sent over the internet as text files and image files. That’s it! human readable text files and pictures. Well I’m leaving out things like flash which is more complicated but for now that’s all you care about, readable text documents and pictures. The web is wide open for all to see that’s why its been so successful and that why its awesome. You could get by with notepad and a free image editor… you’d be better off with other software but it would suffice.

Right about now you’re thinking wow this is really simple… well hang on.

So the web browsers like Internet Explorer, Firefox or Safari for instance all follow the specs (more or less) of the W3C which specifies how all this stuff works namely HTML, CSS, and JavaScript is specd out by ECMA. By the way don’t follow those links and expect to learn much, the W3C docs, just like any spec, are painful to read. So when a user clicks a link to a website from Google the server serves up just the HTML document, the browser reads that document and goes through an amazing series of file requests and contortions until plain text and some images turn into, Facebook, Flickr, Google Maps, CNN etc.

How all that happens is what books are written about, it takes many years to understand all the intricacies of it all but I believe I can explain the concepts concisely… lets see. Imagine four parts of a web site, the textual information or content, the pictures, the arrangement and design of the text and pictures and the interactive behavior of the site. The text/content is the HTML, think of that as the page. When you select “view -> Page Source” in Firefox what you see is the HTML source code. The page requests resources it needs and the browser goes and gets those individual documents to help produce the final product. It will load images, and something called a Cascading Style Sheet. The CSS file defines how the page should look, it also can cause other images to get loaded. Finally external files that contain programmatic code, JavaScript, that defines interactive behavior of the page is loaded. Once loaded in the browser the JavaScript code is executed and it has access to everything, it can change the document by adjusting the style, changing content, adding in new content from other servers and much more. All of this happens within a couple seconds.

How does the HTML define such complex pages as are on the web, how does the CSS style the page, how does the JavaScript produce applications like Google maps…  Its all about the browser and the thing it turns all these files into, the DOM or Document Object Model. At this point you should Install Firefox and the Firebug plugin. Familiarize yourself with Firebug and the DOM, use the Firebug debugger to browse the HTML CSS and JS, then look at it the way the browser looks at it, browse the DOM structure of the site in the DOM tab. Take a look at document -> childNodes -> 1 -> childNodes ->2 etc. Keep following childNodes deeper and deeper in. You’ll see it reflects the structure of the HTML. In the programmatic world of JavaScript everything you see in the DOM tab of Firebug  is available for use. Because the browser turns the text files into these objects, code can be written to modify the page and the attributes of its content. To get a really good handle on it take a look at the “Theory of the Dom” videos by Douglas Crockford over at the YUI Theater.

That’s basically it for core concepts… what I have not covered are the bulk of what you will be learning and that is Object Oriented Programming (OOP), syntax and APIs. Object Oriented Programming is not so complex as you may think, especially since we’re dealing with JavaScript in the browser which is much simpler than say C++ or even Java on the server. Syntax is the rules for how to write a functional HTML, CSS or JavaScript document. Put a comma or an angle bracket or a quote in the wrong place and the page breaks, that’s Syntax. API stands for Application Programming Interface, this is arguably the most common day to day knowledge a coder can have and is often not fully retained but understood through documentation and convention. Everything has an API they are essentially the features available for use. The DOM provides a vast API for programming in JavaScript. Its important to make the distinction between the API and the language. JavaScript is the language, “document.childNodes” is part of the JavaScript DOM API exposed to the JavaScript code thanks to the browsers implementation of the W3C Spec that defines the DOM.

So how about we see some of this JavaScript I keep talking about? Getting back to our example code lets make the page more dynamic using JavaScript. How about loading the the high-res image into the page rather than redirecting the browser to the file. First we’ll modify how the links work by causing the browser to run our code and prevent the default link behavior. That new code will need to create a new image tag using href from the clicked link as the src arrtibute of the new image. We then put that new image into the page. The JavaScript is similar to the CSS in that you can put the code right into the html itself but again I will save it out to a separate file and load it in by adding the following line just before the closing body tag.

<script language="javascript" type="text/javascript" src="simplepage4.js"></script>

First I’ll show you just the code without comments or log messages. Then we’ll go through the actual file that gets run in the browser, it has lots of comments and several logging messages for firebug. If you don’t follow it completely that’s alright this is just a preview but the comments should explain things pretty well.


var imageLinksLoader = {

	init: function(imageLinksDivID) {
		var imageLinksDiv = document.getElementById(imageLinksDivID);
		imageLinksDiv.onclick = function(event) {
			event = event || window.event;
			var target = event.target || event.srcElement;

			if(target.tagName == "IMG") {
				imageLinksLoader.loadLargeImage(target.parentNode.href, imageLinksDivID);
			}

			return false;
		};
	},

	loadLargeImage: function(url, id) {
		var myImg = document.getElementById("largeImage");

		if(!myImg) {
			myImg = document.createElement("img");
			myImg.id = "largeImage";
			myImg.src = url;
			document.getElementById(id).appendChild(myImg);
		} else {
			myImg.src = url;
		}
	}
};

imageLinksLoader.init("imageLinks");

Alright now lets go through it, below I’ve added in comments and logging messages for firebug so you can see how the code runs in the browser.

/*
 I'll be placing several log messages throughout this code so that you can see how things happen by
 looking at the firebug console. If a user does not have firebug installed calling the console.log
 command will cause an error to prevent that from happening we will check to see if console exists,
 if not we will make a fake log function that does nothing.
*/
if(!window.console) {
	window.console = {
		log: function() {
			return false;
		}
	};
}

console.log("the javascript is being initially evaluated (run) by the browser");

/*
 grouping chunks of code:
 lets creat our "namespace", thats a fancy name for saying the container for our code.
 This is not a requirement of the language just a good thing to do.
*/

var imageLinksLoader = {

	/*
	 init is the first bit of code we will run, it is a function that will make the links
	 (when clicked) run our code and will also prevent their default behavior.
	*/

	init: function(imageLinksDivID) {

		console.log('imageLinksLoader.init was called with the parameter "' + imageLinksDivID + '" passed in');

		// grab the item with the provided id, save it in a temporary variable
		var imageLinksDiv = document.getElementById(imageLinksDivID);

		/*
		 a note about assumptions:
		 our code will assume that there are only links that link to other images inside that div.
		 This is an important assumption and right now its obvious but at some point months later
		 you will be editing your html and forget, so document it. Its very important to document
		 your code. Its best to write code that is insulated from such assumptions but you can
		 never totally avoid them.
		*/

		/*
		 adding the event handler:
		 using a nice trick called event delegation we will attatch an event listener to the
		 div it will listen for click events that happen inside it, the oldschool way to do
		 this would be to attatch an event handler to each link, boo too mucch work.
		*/

		// the browser passes an event object as the first parameter we will call it "event"
		imageLinksDiv.onclick = function(event) {

			// with event delegation you can get at the thing that was clicked through event.target
			// that is true except for in Internet Explorer so first we jump thourgh a couple hoops

			// IE doesn't pass in the event object
			event = event || window.event;

			//IE uses srcElement as the target
			var target = event.target || event.srcElement;

			console.log("saw a click on " + target.tagName);

			/*
			 if we clicked an image grab the href from its parent link then call our loadLargeImage
			 function passing it the value of the href which should be the lare image url and the id
			 of the div we want to put it in
			*/
			if(target.tagName == "IMG") {
				console.log("imageLinksDiv.onclick fired");
				imageLinksLoader.loadLargeImage(target.parentNode.href, imageLinksDivID);
			}

			return false; // this line prevents the browser default click behavior
		};
	},

	/*
	 pass in the url of an image and the id of a div and it will get appended to that div
	*/
	loadLargeImage: function(url, id) {
		console.log("load large image from " + url + " into the div " + id);

		// if we already have an image loaded that is the image to use if not create a new image object
		var myImg = document.getElementById("largeImage"); // returns false if we have not loaded a large image yet

		if(!myImg) {
			// looks like no large image added yet creat it and add it to the DOM
			console.log("creating new image object");
			myImg = document.createElement("img");
			myImg.id = "largeImage";

			// set the src of the image object... it will begin loading immediately
			myImg.src = url;

			// and append it to the div
			document.getElementById(id).appendChild(myImg);
		} else {
			console.log("loading a different large image");
			// looks like image was already created so just update its src
			myImg.src = url;
		}
	}
};

// little will happen until we call our init function and tell it what div to work with by passing in the id
console.log("calling the imageLinksLoader.init function to kick everything off");
imageLinksLoader.init("imageLinks");

Actually pretty simple but it encapsulates many principals that are fairly advanced. But enough talk go try it out and don’t forget to turn on firebug and pull up the console tab to see the logs.

Now that I have you thoroughly scared

Let me assure you this is insanely easy to get started with. You’re editing text files not calculating rocket trajectories. Remember the HTML and CSS examples, its pretty damn simple stuff. When it comes to syntax this is going to become obvious because you’ll be working from example and will quickly pick up how to write HTML, CSS and JS simply by looking at a few examples. Then once you get the syntactical pattern you have to know what you have available in your toolkit, the API. Great news on that front as well, it is all very clearly laid out in simple descriptions all over the web called “API Documentation” and I’ll provide several such resources. Finally when you use a proper code editor it holds your hand the entire time, helping you learn by telling you the instant your syntax gets messed up or showing you all the appropriate API features you could use at any given point. It is almost too easy to dive into web development. Lets not forget there have been so may that had to learn all this without the benefit of the now accumulated wisdom of the professional community, the amazingly helpful tools like Firebug and the Safari Inspector, real coding tools or the amazing panoply of educational resources or understanding of the bugs or the help of libraries like jQuery that simplify the JavaScript to an unbelievable level. You benefit from millions of man hours of hair pulling and painful development and documentation. Basically you’re standing on the shoulders of giants.

Develop a collection of top-notch resources

I’ll get you started but you should always be on the lookout for new sources of examples, tutorials, best practices, industry trends, reference material, inspiration and good ideas with a strong eye towards exceptional quality vs quantity. Finally there are tons of advanced tutorials and examples of new “better” ways to do this or that, you’re just starting out, stick to the basics to begin with and when you have a firm grasp on them then slowly branch out to try something more complex and interesting.

The Basics

  • w3schools.com – “Because time is valuable, we deliver quick and easy learning. At W3Schools, you can study everything you need to learn, in an accessible and handy format.”
  • developer.mozilla.org/en/Web_Development – When it comes to reference material you can’t do any better than Mozilla’s Developer center. Got a question about a specific feature of html, css or javascript? Just Google it followed by MDC for quick access to Mozilla’s documentation. eg. “javascript array mdc”, “css background mdc”
  • csszengarden.com – The  one and only, classic, learn by example, temple of “separation of content and design”. From the site: “There is clearly a need for CSS to be taken seriously by graphic artists. The Zen Garden aims to excite, inspire, and encourage participation. To begin, view some of the existing designs in the list. Clicking on any one will load the style sheet into this very page. The code remains the same, the only thing that has changed is the external .css file. Yes, really.”

JavaScript:

PHP:

Photoshop:

Becoming a Master:

  • alistapart.com – “A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices.”
  • boagworld.com – “Boagworld is the web design blog of Paul (the Wurzel) Boag who lives in the heart of rural Dorset. He produces a weekly podcast with Marcus (pop star) Lillington on all things relating to building and running websites. They also run web design agency- Headscape.”
  • net.tutsplus.com – A great collection of tutorials, screencasts and articles covering a wide range of web development topics.
  • smashingmagazine.com – Graphics, Inspiration, Coding, Design, Photoshop, WordPress, Tutorials, Wallpapers, Icons, CSS.
  • css-tricks.com – Another excellent web design community, a great resource for, tutorials, screen-casts and code samples.
  • ajaxian.com – keep up with the latest and greatest in web application development

The above represents a minuscule cross section of the best resources available yet alone they open up a huge world. Keep looking and learning every day. It’s a good idea to set up a feed reader like Google Reader to more efficiently scan through all your resources every day.

Your IDE is your best friend

IDE stands for Integrated Development Environment. Why waste time learning an IDE that is not going to grow with you… Go ahead and dive into the real thing right away. Go get Aptana Studio which is based on the amazing Ecliplse IDE. Like it says, its “the leading IDE for web development” and its FREE! Once you have it installed get to know your new home, kick the tires, wade through all the preferences and menus. Then go watch some of the training videos (avoid the ones about plugins.) Some day someone will tell you to switch to a different IDE for x, y and z reasons. This is fine but start out here with a real IDE and when that time comes around you’ll have a better idea of what features you care about.

Intro to Aptana Studio from Aptana, Inc. on Vimeo.

Photoshop, just get it already…

One of the tools that you absolutely can not skimp on is Photoshop. Now there are proponents of GIMP and other free software, a search for “Photoshop alternative” will expose many such would-be replacements of this essential tool. But they don’t come close, not by a million miles. That applies especially to anything with Photoshop in its name that is not Photoshop CS or later, that means no Photoshop Elements, no Photoshop.com. By hook or by crook you gotta get the real thing. Some people are content to scour the web for hacked downloads through bittorrent. I’m sure you could find it but I’m sure you’ll probably contract a virus in the process… I suggest AVG for that (virus protection) but better yet get your hands on the real thing, yup just pony up, then there is no concern about viruses or breaking the law.