What does any of that have to do with Codekit? Once you get use to the idea of being able to break your project up into resources that get imported and referenced as needed, it becomes a little daunting to think about the mess a large Javascript project can become. Unless you spend the time to properly organize yourself you’ll quickly be looking at a 1k+ line single Javascript file that becomes a headache to try an maintain. Or you’ll have a folder full of resource, and since Javascript isn’t compile, a ton of browser requests to go along with all those resources.

That’s really at the hear of what CodeKit does so well. What drew me into using CodeKit in the first place was the easy support for Less and Sass. What kept me using it rather than any other command line tool was it’s awesome support for Javascript includes. I’m able to organize all the javascript element for this website into nice and small files that are easy to maintain, but at the end of the process I’m only dealing with 1 request back to the server for my Javascript, and 1 request for my CSS. I structure my javascript on my personal machine like this:

site
|____resources
|       |___ trees.js
|       |___ leaves.js
|       |___ daycycle.js
|       |___ pikachoose.js
|       |___ fancybox.js
|____functions.js

Each of the files in the resource folder holds a separate part of my site’s functionality such as the leaves on the portfolio page or the shadows/trees that are drawn in the header. Each of these snippets of code are self contained, but more importantly only give me access to the tools I’ll be using (functions for drawing items like a tree) rather than execute the entire process. I rely on my functions.js file to handle all the logic behind calling these methods.

My functions.js file starts off with a //@codekit-prepend “resources/trees.js”,”resources/leaves.js”,”resources/daycycle.js”; After everything is pulled into the one file I then start my jQuery logic in a document ready call just like any other jQuery file, but all the functions I want to reference are now easily accessible with only 1 request made by the browser!

One little snafu I had that was cleared up by developer @bdkjones was commenting out the CodeKit prepend statement. CodeKit does not remove this line, so unless you comment it out you’ll receive a syntax error when the browser attempts to load your Javascript. CodeKit pulls in the corresponding files and depending on your settings will also minify them reducing the server load even more.

I also apply this same type of organization to my CSS styles. Since the big hype right now is responsive design, stylesheets are starting to get larger and much more complex. I use the Less compiler in CodeKit to help ease this burden. I can take my 3 stylesheets and combine them down into one minified stylesheet. I keep the style broken out by screen size, fullsize.less for the standard styles, phone.less for lower resolution specific items, and print.less (still a work in progress) for printing.

Well CodeKit may not replace all the needs I have, it does make my day to day development a ton easier! If you haven’t check it out yet you can at http://incident57.com/codekit/ for the next couple weeks until it officially launches in the App Store. It’s a free beta, but should be available for around $20 when it launches officially. I’m a tightwad when it comes to development tools, but this is $20 I will gladly spend as soon as I can.

The change wasn’t too hard to make since I’ve been using OS X at work, but I had to find a replacement for all my Windows Dev tools. Here’s my list of tools I use in Windows and their OS X equivalent where they exists.

MySql Client

Navicat

This one was an easy switch. I’ve always been a fan of Navicat for Mysql, it has a very decent user interface. Navicat lets you save queries for easy access to data. The graphic interface makes navigating your databases and tables a breeze. There’s even a feature in the full version that lets you backup databases with the click of a button. The best feature? It’s available on Windows and OS X so there’s nothing to worry about when making the switch!

Terminal & SSH Client

Windows:

For a long time I was using Putty for my SSH client. Well it certainly was adequate, it doesn’t feel anything like using the Linux or OS X terminal. Because of that I made the switch from Putty to Cygwin. Cygwin gives you Linux like terminal access on your Windows machine. SSHing into a remote machine is handled just like it is in Linux or OS X and there are a ton of great plugins to add even more functionality.

Mac:
Now it’s tempting to just settle in and use the built in OS X Terminal app. Well the Terminal app works well without any short comings, iTerm2 takes it to a new level. iTerm2 adds in a ton of awesome features like split pane windows, searchable histories, paste history and autocomplete. Well none of these improvements make a huge difference by them selves, when added together they make a huge difference.

Another awesome feature of iTerm2 is the ability to use a code syntax theme. Well this may not seem like a huge feature at first, once you start using a syntax theme across all your programs it makes switching between editors (Coda to iTerm to xCode) less jarring.

PHP, Javascript, and HTML

Windows:

PHP Designer

For PHP/Javascript I’ve been a big fan of phpDesigner 8. It has great auto completion capabilities that make coding in PHP a dream. It also has syntax support for Javascript, HTML, and CSS3. It will quickly highlight any syntax errors as you type. phpDesigner will also keep track of your custom classes and will add them into its auto complete library.

Mac:

Coda

Now if there is one area that I’m having trouble matching my Windows development tool, it would have to be a code editor. Currently I’m using Panic’s Coda to do development in OS X. Well it’s a beautiful editor with built in FTP and decent code completion, it’s severely lacking in other aspects. It has serious problems with syntax error detection. There’s some decent plugins out there that make up for some of Coda’s short comings.

Development Effeciency

There are a couple tools that I haven’t found an equivalent of for the other operating system. One of my favorite new tools is CodeKit by Brian Jones. Codekit takes all the manual work out of minifying and packing your Javscript and CSS files. It can watch a project directory and will easily pull in any changes and spit out a gorgeously minified version ready for uploading.

As if that wasn’t enough, CodeKit also lets you take your pick of CSS languages. I’ve been using LESS for my more recent projects, but you can also take your pick of SASS or Stylus which compile automatically. No need for any Ruby scripts or client side Javascript, CodeKit handles all of it.

Should I place my Javascript in the footer or in the header is a question I’ve seen come under fire a lot lately. There are numerous blogs touting the advantages of moving all your Javascript to the footer. I haven’t seen any articles on why moving your Javascript to the footer, or wrapping all jQuery in a document ready is a bad call.

Moving your javascript down the page does have a lot of advantages. To use a common phrase: “Content is King.” When a user visits your site the first thing they want to see is content! By pushing scripts to the bottom of the page you free up the browser retrieve and display content first. But there are some serious questions you should ask yourself before you move all your scripts to the footer.

Does this Javascript have a profound impact on the users experience? Does your script dramatically change the way content is displayed or interacted with on your page? If it does, it is worth weighing the what is more important to your visitor. Take a look at Woot.com for example. They sell 1 product a day, so obviously the most important thing to their visitors is seeing what that one product is. If you click on the image as soon as it’s visible you get taken to the full size image on a new page. But what if you wait for the page to load? Now your presented with a slideshow of images showing the product from every angle.

This is a prime example of when not to move your scripts to the footer. When I visit Woot.com the first thing I do is click on this product image. If I click too early I’m punished for it and have to click back on my browser and wait patiently for the page to finish loading. Depending on what time you view Woot.com has a pretty dramatic effect on load times though. Which raises another question.

Does my ad network have an effect on my scripts? It’s not that the whole page is loading terribly slow, it’s that sometimes the ad network is performing painfully slow. This means I get to wait for the ad network to respond before I can use the page the way it was meant to be used. Keep in mind that some ad networks load asynchronously and will not cause your page to hang, but there’s a lot of them that don’t. Be mindful of how your ad network delivers ads and adjust your scripts to give a better user experience.

Should I user $(document).ready with my jQuery? Now that frameworks like jQuery and YUI are becoming excedingly common, it’s worth looking at how they are effect by script placement. The $(document).ready call with jQuery waits for the entire DOM to be present before running any scripts (this is different than waiting for the page to load). Let take another look at Woot.com. Their account/login buttons are shown by Javascript.

What I find interesting though, is that which div to display (login or account) is delayed until the DOM is loaded. The account button shown there is the only way to navigate to your account page, but once again you have to wait for the ad network to deliver ads before the rest of the DOM is loaded. If things are moving slowly that day, you have to wait up to 5 seconds to see something that is loaded and ready, but hidden from you!

How can you fix this issues? Be careful about what you put in the footer and what you put in a DOM loaded function. If you have something user critical, don’t be afraid to toss in a script tag just after that element with whatever Javascript is needed to make it function correct.

Take advantage of Google Libraries API. Using a Google hosted version of jQuery (or other framework) gives the best chance that your visitor has a cached version, saving load times while keeping the script in the header. Also look at options of compressing or minifying your Javascript so it can live in your header but with a reduced file size.

Don’t use Javascript for critical functions on your site. Yeah I know it’s 2011 and Javascript is no longer thought of as an evil thing, but there are still people who chose to browse with Javascript disabled. Keep this in mind when developing and as yourself if you could achieve the same effect with CSS or some server side script.

There really isn’t a do this, or don’t do this answer in the end. You have to use your better judgement and remember that just because someone says you should do it, doesn’t mean it right. Always step back and try to look at thing from the visitors perspective. What am I here for? What do I want to do or see first? In the end you always want your average visitor to be happy, not the guy checking your source and looking for where you included your Javascript.