9 months with Codekit - A Codekit 2 Review

Quite some time ago I wrote a mini-review of Codekit 1.0 and then another review of Prepros. Admittedly I had only been using pre-compilers for several months at that time (what a difference a year makes).  Now that its been over two years down the chasm of Sass and a more varied workflow, I feel that I can expound in ways I couldn’t before. I’ve blogged about Codekit 2 error resolutions which have been referenced on Stackoverflow.com by people who aren’t me. While I may not be the foremost expert, I believe that I have some credentials to speak with some authority on pre-compilers and CodeKit specifically. 

I haven’t seen any massive reviews on CodeKit 2 either, since its a niche market so I’ll try and make this the most definitive review written to date on CodeKit 2. I’ve also continually added thoughts and notes at the end of this review. Its been over 21 months with Codekit since the original review, which is still accurate thus almost untouched.

Now, that we’ve gotten that out of the way, let’s get to the heart of the matter at hand, shall we?

Depending on your comfort level, there’s a few items I’ll be discussing at great length, if you’re a grizzled vet, you may want to skip to the review part, otherwise keep reading. :)

Quick Glossary

Preprocessor - a utility that converts one type of data into another type of data  that another program can use. This is often used as a blanket term for programming languages that require a preprocessor. Sass and Less are often referred to as preprocessors.

Compiling - converting code into data that a program or OS or web browser can understand. In regards to web development, preprocessors are used for languages that when compiled (processed) export a file in a common language such as Sass to CSS or Markup to HTML. There are many types of compilers and interpreters that differ wildly depending what platform and programming language are used. When I am discussing compiling for the sake of this article, I am strictly talking about compiling code with a preprocessor in order to spit out code in common web languages that are read by a web browser.

Task Manager - a program that automatically performs common tasks, usually when triggered. Task managers can “listen” and automatically run a series of instructions based on an event. For web development, this usually means when a file is saved or project structure is altered, then it will trigger a preprocessor to compile code,  reload a page and other common tasks. Popular preprocessors include:

• Codekit - A Mac only utility with a graphical user interface
• Prepros - A cross platform utility with a graphical user interface
• Grunt - A command line utility built on node.js
• Gulp - a command line utility

Package Manager - a package manager is a way to automate the process of installing, upgrading, configuring, and removing software. Bower is the most popular package manager for front end developers.

Minification - Every keystroke takes up minuscule amounts of data, measured in bytes. Minification takes out unnecessary keystrokes from HTML/CSS/JS and creates a “minified” version of your code, With Javascript, even variable names are replaced with short names to save data known as uglification. Since HTML/CSS/JS are the instructions that your browser needs to render the page, this will help aid page load speeds considerably.

Concatenation - Concatenation (concat for short ) when programming means combining to two variables’ stored values. When applied to file management, concatting means combining multiple files into one file. This allows for example, many javascript files to be combined into one JS file for distribution. This reduces the amount of requests a web browser must make, and thus (usually) speeds up the data transaction from the web server.

Why do we need Sass and Less?

CSS as it turns out is missing some very powerful features such as using variables, the ability to create things programmatically or the ability to nest  attribute.  Clever developers created  Sass and LESS as CSS-like programming languages to add these sort of functions to CSS. Both languages when compiled output plain ol’ CSS. It just makes writing very complicated CSS faster. Other developers have attempted to do this same thing with Javascript with CoffeeScript and Typescript, and even HTML.

There’s plenty of places other than here that can better explain what Sass and Less are and chances are if you’re reading this review, you probably already know.

What is CodeKit?

Simply put, CodeKit is a task manager that allows you to automate code compiling for popular preprocessor languages.

CodeKit for all intents and purposes manages projects akin to Grunt.js and Gulp.js and works with Bower, so you can easily deploy code.

CodeKit takes the place of using esoteric software packages like Grunt and Gulp and attempts to make it much easier to use.  It comes out of the box with support for several very popular Sass libraries like Compass and Susy, which allow you to execute functions from these libraries without installing them manually. 

The advantage of CodeKit is a much more familiar drag and drop approach which is more comfortable to many users.  

Setting up a project requires simply drag and dropping a folder onto Codekit. CodeKit will automatically detect the languages in the project and then allow additional configuration.

CodeKit can take the place of several utilities depending on how it is set up and even be used to assist project setup.

About my workflow and technologies

Workflows are everything in web development, everyone has their favorites. Take for instance an IDE: you have the VIM purists, Textmate lovers, oldschool BBEdit fans, Coda junkies, the large swath of Sublime Text users, the alternative Espresso crowd and the Github Atom fanboys. That’s just for a text editor, so I’ll try and keep this short as I believe its important to disclose so others can compare and contrast.

At my current job, our tech stacks vary a lot. In the last year I’ve worked on projects that use Django, Drupal, Wordpress, Expression Engine, internal PHP, Python, Angular, Jekyll and even an ASP.net project and a few old Coldfusion legacy sites. 95% of our sites are Sass, although there a few LESS projects and even one plain ol’ CSS site.

Internally, we have staging servers managed by Jenkins. Most of the time work off of a localhost using Apache (or Python’s server). 

On an average day I’m bouncing between Sublime Text, Tower (Git), Photoshop, ImageAlpha+ImageOptim, Sketch, VMware/simulators and a host of small utilities (Colorsnapper, Rulers, GhostLab)  along with whatever tech stack I’m working with that day. 

Now to the review part

CodeKit does what it advertises, and does it well.   All the options you’d expect are represented in  the settings panels, including settings for a few popular frameworks such as Zurb Foundation, Burbon, Compass and Susy. 

It takes me usually less time to configure CodKit properly than it takes to set up a grunt or gulp file. 

CodeKit also creates a CodeKit config file based on each project, which makes projects sharable with other users for minimal configuration. This is great for working with other developers using CodeKit, or a single developer working with multiple computers.

Image Optimization

CodeKit offers image optimization akin to ImageOptim or a grunt task. Its the low hanging fruit of image optimization and will losslessly reduce jpgs and pngs. File  size savings vary based on images. 

It provides a baseline optimization, but users looking for better  image size reduction will want to use specialized utilities like Fireworks or  ImageAlpha.

I found myself almost never using CodeKit’s image optimization, as I tend to process all my PNGs using ImageAlpha.

Code Compiling

The heart of CodeKit is it allows you to automatically compile and concatenate a plethora of languages: Less, Sass, Stylus, Javascript, CoffeScript, TypeScript, Haml, Jade, Slim, TypeKit and Markdown. Languages can also be minified and include features like auto-prefixing and blessing, and even supported now in Compass projects as version 2.1.9.

Code compiling requires minimal set up, CodeKit will analyze your project on drag on drop but you may need to specify where compiled code ends up.

Once connected to CodeLit’s internal server wrapper, simply hit save, and CodeKit will inject your CSS changes to any web browser or reload the page on Javascript/HTML/PHP/Python changes.

CodeKit’s code compiling is reliable and when you’re in a bind, you can specify external compilers. External compilers are Ruby gems installed usually for the CLI. It means if Compass (for example) is updated, you don’t have to wait for CodeKit 2 to be updated. 

CodeKit’s error log is fantastic. However, when specifying external Sass compilers, I noticed sometimes the error logs displayed generic errors, which weren’t very helpful.

Internal Servers

Codekit 2 also does a fantastic job with external servers (locally hosted or external) which can be accessed by other devices on the network: be it a virtual machine, another computer, a mobile device and so on.  Any changes to the CSS are injected without needing a browser refresh. Editing PHP/Python/HTML/JS (or other defined files) will trigger any browsers to refresh.

CodeKit however, lacks an external inspect element like Prepros has, or address following like GhostLab. Its good but not as robust as other solutions. Any injected CSS changes are animated. Its gimmicky to see colors fade into the new value or objects change in shape or size but it also is useful as you can track all the elements that are changed.

Its fantastically useful, especially on locally hosted projects as it allows you to easily connect from an external device or virtual machine. While I’m a fan of GhostLab, I found myself eschewing it for a leaner setup of simply CodeKit on day to day operations.

Currently, IE10 and IE11 give JS errors when connected to the server, other than that live refreshing mostly works. Hopefully the bug will be resolved.

Package Management

Package management is one of my least used features of codekit… It has to do a lot with my work flow, and the way our staging servers are configured and my general laziness towards concating bower packages into my tasks, and my bad habit to often trim down popular front end Sass libs.  When I do, I use Bower from a CLI.

I’ve tested CodeKit’s Bower Package Manager, and it works but it saves almost no time if you’re creating a json file for bower. The GUI makes  finding projects easy and simple.

Source Maps

Source maps are a fantastic innovation for development, as source maps cite original source code for compiled code, allowing you to easily debug and troubleshoot.  CodeKit offers source map support which is crucial.

In terms of Grunt…

It’s impossible to describe CodeKit without comparing it directly to Grunt, its free CLI alternative. However, the utility of a such program like CodeKit is called into question as Grunt can be configured to do everything that Codekit does: image optimization, compiling code, injecting CSS changes and minification. In fact, grunt can do a few things Codekit can’t such as SVG optimization, which begins to beg the question why use Codekit in the first place?

CodeKit’s biggest advantage and disadvantage is that it lets easily create projects and workflows without Grunt. It takes admittedly a lot less time to start in on a CodeKit project. The interface lets you plug in all your defaults in a nice handy GUI without having to go through the steps of writing JSON in a gruntfile.js.

This is exceptionally empowering but somewhat limiting, everyone in your team will need a copy of CodeKit or will need to create separate task manger (grunt/gulp) to compile the Sass.  

Since CodeKit has a GUI, it  makes bouncing between projects quicker and faster than starting/stop Grunt watches. You can switch projects quickly by clicking the project you want to bounce into and it’ll automatically start watching the project files in that project, and swap your server. Codekit also tends to eat less CPU cycles than a Grunt Watch task, its better for battery life than a complex grunt task.  

CodeKit also lets you use Libsass, a Sass compiler written in C instead of Javascript. Since the code is native to the operating system, it compiles code much faster. It greatly speeds up build times, but also may not be compatible with some Sass libraries. It’s simpler than installing and configuring libsass for Grunt. 

Libsass still has its limitations, Libsass currently is incompatible with Compass and still has yet to catch with Sass 3.3 features. CodeKit automatically defaults to a non-libsass compiler for Compass projects. Its one less thing to configure properly when using CodeKit. 

Lastly, CodeKit has hooks and allows you execute Bash or Applescript after CodeKit compiles. Using hooks, you could potentially upload your changed CSS after a compile to an FTP.  Hook functionality allows beyond some of Grunt’s capabilities. To be fair, since Grunt at root is a task manager, it can be configured to execute commands like SVG or HTML minifying which CodeKit currently cannot.

Codekit 1 vs Codekit 2

Codekit 1.0 never quite fit my workflow in the way I wanted it to. A short list of complaints:

• it had maximum file watch limitation
• it wasn’t as fast as libsass
• the interface wasn’t as straightforward
• it didn’t support the latest compass
• its CSS change injection was severely limited (it’d reload Safari/Chrome’s front-most tab), not the tab with actual website..
• it’s internal server didn’t support external URLs

CodeKit 2 fixed every last one of these complaints. It’s nice to see an application evolve so elegantly. I’d still like it to borrow a few features from Prepros, mostly in the server department. More on that later…

So who is CodeKit for and is it worth it?

CodeKit is the everyman’s task manager. Its much easier to use than grunt and a great way to get introduced to the world of preprossing as you can concentrate on learning the language instead of writing esoteric grunt and gulp commands. This alone makes it worth $29. Anyone looking to start using Sass or Less probably should start with CodeKit as they can focus on coding and not setup.

When I started using preprocessing, I barely understood what Grunt was doing and found configuring it frustrating. I’m not afraid of a CLI but I find GUIs more intuitive.  Codekit 1.0 was my introduction to preprocessing but working in a team environment developing websites, I ended up simply using grunt files that I was given, or using Prepros.

Later, when I was lead on a few projects, I ended up having to configure grunt files in case we needed to bring in other developers. When CodeKit 2 was released, I was comfortable with grunt configuration.

CodeKit 2 feels like a different tool. Its polished and powerful. Its fun and quick to use… but unnecessary. To use it on projects, requires me to configure Grunt first then CodeKit.   I’ve found myself recently starting to favor Grunt again. Its more flexible, and has sped up in recent versions.

CodeKit vs Prepros

In my review of Prepros 4, CodeKit 2 had been release the same week as I was finishing up my writing. Ironically, Prepros 5 was released while writing this particular review. Codekit 2 has a leg up for speed and compatibility, and distributability (thanks to its pref files stored in projects). 

I abandoned Prepros 4 entirely for CodeKit 2 and didn’t look back. Prepross still has a few things CodeKit doesn’t, mostly the ability to inspect element on external devices, automatically detects VPNs and displays internal and external IPs for its internal server, and the ability to serve many projects without having to switch projects. Lastly, Prepros is cross platform, which is a big deal.

Running Grunt on Windows  is painful on Windows. It makes more sense to want a GUI task manager on Windows as you’re not in a *nix environment where you can natively run many common command line utilities.

CodeKit really could take a page from Prepros’s (and GhostLab’s) more powerful server. The ability to remotely use Inspect Element without any configuration can be insanely great on older devices and browsers. Plus the VPN detection is a nice touch. Prepros 5 boasts browser click syncing and following, akin to GhostLab and BrowserSync, FTP support, and now boasts Libsass and ability to use external compilers putting it in the running with CodeKit for speed. I’ve yet to use Prepros 5’s browser syncing but if it works anything like GhostLab, it’s a killer feature. 

Prepros 4 was a better product that CodeKit 1.0. CodeKit 2.0 is better than Prepros 4. The question now is if Prepros 5 is better than CodeKit 2.0? Based on toying with Prepros 5, its a tie or at least fairly close. Update: Codekit 2.0 is the better product. 

The biggest differences are:

• CodeKit’s per project config files (correction: Propros does have per project config files that can be distributed) make CodeKit more compelling for teams, ability for hooks, external compilers support, has built in package management, Syntax Checking,  and framework support.

• Prepros has a more robust external server with remote inspect element and scroll/click syncing, and FTP.

After using CodeKit 2 and managing to resolve some major errors using external compilers, and the ability use JS syntax checking, CodeKit 2 is the better task manager.

Final Thoughts 

Pros 

• CodeKit 2 feels like brand new product compared 1.0
• Fast. Libsass is super fast Sass compiling!
• Massively improved server.
• Cleaner user interface.
• Bower Package Management
• Animated CSS injection
• Easy project configuration
• No more file watch limit
• Compass is built in and can be manually configured
• Codekit Config files can be distributed with project
• Very low learning curve!
• Faster than Codekit 1 or Prepros 4
• External encoders
• Less resource intensive when idling than Grunt
• Easy to read Error Log

Cons

• Must make current project active
• Server isn’t as robust as Prepross or GhostLab
• Grunt is free and once you get over the configuration hump, more flexible and powerful.
• Trouble shooting esoteric errors will probably land you at my blog
• No built in FTP support

I highly recommend CodeKit 2, especially for people looking to get serious about web development. 

CodeKit doesn’t offer anything other than convenience and speed for seasoned developers comfortable with grunt. My days are limited for CodeKit 2 professionally, but I got my money’s worth and then some. Depending on your tech needs, you may not outgrow CodeKit as fast or at all. 

It’s worth noting CodeKit 1.0 had rather robust support after version 1.0, two years of free updates, more frequently than its competitor, Prepros (although version 5 was a free upgrade). 

Troubleshooting CodeKit is a bit of a crapshoot. Since I’ve become much more technically competent, I’ve taken it upon myself to blog every time I encounter a CodeKit 2 error and how I personally resolved it.  Even the day this review went live, I found myself queuing up another CodeKit 2 troubleshooting post. CodeKit takes a lot of the sting out of front end development but it really helps to have some CLI chops and a deeper understand of task managers. If you’re looking to avoid Bash (the terminal app) in OS X, CodeKit is only a band-aid as even CodeKit users such as myself benefit from having a basic understanding of what’s happening. To CodeKit’s defense, the errors are dependent on the technology CodeKit is built on and rarely CodeKit 2 itself. CodeKit 1.x had a habit of crashing, CodeKit 2.0 almost never does.

Lastly, the author of CodeKit, Bryan Jones has a pretty good sense of humor. It’s a weird thing to note, but sprinkled through out his website for CodeKit and anything pertaining to CodeKit are some gems. Its the sort of humor that’s pretty fantastic when you spend all day developing websites and probably not so funny if you do just about anything else.

I have a short wish list of features for CodeKit, a few are pipe dreams and a few are likely:

• Optional Remote Inspect Element (FireBug’s JS beta or otherwise would do nicely).
• Remote server tuning (I get JS errors in IE10 and IE11)
• SVG minification
• Ability read Grunt or Gulp tasks and pair them to CodeKit’s functionality (A man can dream…)
• Ability read Bower configurations and automatically install missing libraries

I happen to have wildly changing tech stacks and projects that ship after only a month of development and service agreements to maintain.  Milage may vary but if the worst thing you do is outgrow CodeKit, you won’t regret your time spent with it.  I haven’t. 

/edit: CodeKit 2.1.9 was released a day before this review went live, suggesting a trajectory away from Ruby configs, in favor of a more centralized preferences to enable things like Bless and auto-prefixing for compass projects.  CodeKit continues to evolve and make life simpler. I’ll eventually review Propros, but writing 3500+ words is time consuming. 

Codekit 2

Version(s) reviewed: 2.0 - 2.1.9

Price: $29

Incident57.com/codekit

Update - December 1st, 2014:

CodeKit 2 still has use even in my post CodeKit 2 workflow.

I was working on a Wordpress + Grunt with Browser sync. It had already gone to our QA process and thus I was fixing IE8 errors, using a standard workflow: local machine to git push to  staging server.

However, I had disabled browser sync as I was nearing production (BrowserSync requires pasting in a JS file into the footer of the site) and needed to quickly test on my IE8 virtual machine off my local wordpress install.

GhostLab refused to play nice with IE8, severely borking the site. CodeKit 2’s internal server came to the rescue, easily serving up the site to my VM.  

Update - April 8th, 2015:

I’ve all but stopped using CodeKit except when dealing with IE8 since GhostLab doesn’t play nicely with it. CodeKit is a fantastic app but moving forward as I’ve gotten deeper into grunt with grunt, all future projects probably won’t include CodeKit 2.  

This isn’t to say that CodeKit is beneath me or a lesser product but with the technical demands of my job I’ve moved outside its scope. CodeKit works reliably enough to be used in a professional setting, and I can say that with sincerity as I did for the company I work for. We’re a little more tech heavy as a do-it-all digital agency.

If you aren’t using Sass or LESS, and reading this, buy CodeKit 2 now. Sass isn’t the future of front end development, it IS front end development.

Update - August 24 2015 - Prepros: 

I finally posted my Prepros 5 review. Writing 2500 per review is exhausting but forcing myself to review a product that I haven’t had time for is more so. There’s still things I’d of liked to say but scrapped for timeliness.  The big spoiler? CodeKit 2 is a better product more suited for a professional environment. 

CodeKit 2 still is being updated, mostly with the latest precompilers. Reading my last update makes me think: “Ghostwhat?” I haven’t fired that up probably since writing the post now with BrowserSync arriving. Gulp and Grunt are just too damn powerful.

Update - late December something 2015:

I finally got around to working on redoing greggant.com, still a work in progress. I could have used Gulp or Grunt but as a single developer, with only a local Git repo, I ended up firing up Codekit and enjoyed the braindead simplicity of just writing code without all the usual leg work. 

It reminded me of using Reason after years of using Cubase. Instead of spending time configuring, I was simply composing. It wasn’t the best tool but it was the right tool just beat out a melody. That’s Codekit.