If you’ve ever worked with Sass or Less, chances are you’ve used CodeKit. An application that helps you speed up your workflow with automatic file compilation, browser-auto-refresh and built in syntax control among many other features.

After having worked as a freelance web developer, Bryan Jones decided to purse a career in business administration in North Carolina. In his spare time he  continued to develop for the web, but realized that there were no good tools for handling pre-processor languages such as Less. He started creating a plugin for Coda, which later became the Less.app. But with the rise of Sass and other extension languages such as Coffeescript, he decided to create a full blown application for all of them, CodeKit.

With the much anticipated release of CodeKit 2, I wanted to have a few words with Bryan about the goals and development of the new version, as well as future plans.

When did you decide that this could, and would, be your full time job?

I put CodeKit 1.0 on sale in April of 2012 and finished up my MBA in May of 2012. I then spent the next few months slowly searching for a job in a finance-related area. I was just about out of money before I shipped the app and I figured that CodeKit had given me a little breathing room — I could pay rent using the app for a few months while I found the perfect job instead of jumping at the very first thing someone threw my way.

As the summer continued, it dawned on me that Codekit was doing well enough that I didn’t need another job to support me. That’s when I decided to simply work on the app full-time. I have been very lucky and I have the best customers anybody could ever ask for.

How did you feel when large companies such as Google and General Electric started to use your app?

It was surreal more than anything else. I still can’t believe these folks use something that I created.

What was your goal when starting to develop CodeKit 2? What did you want to improve from the previous version?

I had two main goals:

  1. To make my designer’s (Guy Meyer, @agenericguy) life a living hell.
  2. To make an app that looked and worked like it could have come from Panic.

I definitely accomplished the first goal. I’m not sure I’ll ever meet the second. But at 3:30AM when I had a feature “working” but not perfect, that second goal is what would gnaw at me:

“It works. It’s late. Let’s go to bed.”
“Yea, it works. But it’s ugly or cumbersome or a little weird to set up. You know they’d do it better.”
“Goddammit. Fine.”

What is your favorite feature in the new CodeKit?

This has to be the live reloads across devices. Watching CodeKit instantly refresh the browser on 20 devices at once is really something. It feels like magic even to me, and I’m the guy that coded all of it!

Did you face any big obstacles developing it?

Oh god yes. Source maps were a huge pain. The spec for them kept evolving and most of the initial implementations by each of the compilers inside CodeKit were incredibly buggy. To this day they’re sort of a, “60% of the time, it works every time!” deal.

Working with all the idiosyncrasies of various platforms like WordPress and Drupal was also challenging. Building support for them so that CodeKit’s proxy server didn’t break them was very time-consuming.

I also spent an entire day tearing my code apart to discover why CodeKit was failing to refresh PHP files as I saved them only to find that the folks over at MAMP decided to enable OpCache by default. (OpCache caches PHP files and continues serving the cached version rather than reloading the file from disk.) Obviously, this is a very dumb thing to turn on for a development environment where your files are constantly evolving. I have no idea why they decided to do it, but I made CodeKit smart enough to detect it and offer to turn it off for you. I like to think that attention to details like this is what separates CodeKit from other apps.

Grunt became really popular after the release of CodeKit 1 and was quickly adopted by a lot of developers. Did this affect your work when developing CodeKit 2?

No. Grunt is a great tool built by really talented people. (They’ve probably forgotten more about programming than I’ll ever know.) But Grunt had no effect on my plans for CodeKit 2.

I don’t really view Grunt as a threat. This surprises people, I think. Grunt is aimed at people who like command lines and manually writing configuration files and pouring over documentation to tweak settings and debug things. And I don’t mean to imply that these people are dumb or crazy. I mean that these people probably weren’t potential CodeKit users to begin with.

CodeKit’s whole message is: “Hey, fiddling with command lines, writing JSON files and deciphering threadbare documentation sucks. Why don’t we just skip all of that and get to work?”

I see Grunt as a complementary tool; there’s plenty of room for both it and CodeKit to exist and thrive. That said, it does make me very happy to get emails from folks that try CodeKit after using Grunt. They’re always surprised at how much faster my app is. It should be; most of CodeKit’s critical performance algorithms are written in C. Grunt has to handle everything through a Javascript runtime. Javascript is pretty snappy, but nothing is going to rival C.

The other thing that makes me smile is seeing posts (usually on Hacker News) that go like this: “Why would someone write this app when Grunt exists?” Son, I was writing apps to support pre-processors before Grunt was even a thing. And as hard as it is to believe that ANYTHING ever existed before Node.js, my apps did. When I started, Sass didn’t have the *.scss syntax and Less was written in Ruby, not Javascript. Posts like this make me think of the funny meme: “Why are all these old bands covering Glee songs?” I am the Bruce Springsteen to Grunt’s Justin Beiber.

What made you decide to go for Libsass, a new faster compiler for Sass written in C. As to use Ruby, which is slower but has better support?

Well, for starters, we use Sass on the CodeKit website and waiting 3-5 seconds for it to compile was annoying. So, I wanted libsass for my own use.
Secondly, my designer Guy Meyer showed CodeKit 2 to the guys at Zurb a few months ago and the first thing they asked was, “Does it have libsass!?” That convinced me I had to add it officially, even though it’s still in beta.

Any plans for new cool features in the future?

I’m going to go with the standard Tim Cook answer: “We have some amazing new products in the pipeline.”
CodeKit 2.0 was a ground-up overhaul of the entire app. It’s over 1,300% faster than 1.0 because I re-architected everything and optimized every algorithm I could. The move to 2.0 was about getting to a codebase on which I can expand. You have to remember, when I wrote CodeKit 1.0, I never expected the app to become wildly popular! I built that version without a good idea of what I would need to support in the future, so it was not very flexible from a development standpoint — adding new features usually equated to major surgery.

By contrast, this time around I had lots of experience so I could build the app’s architecture in a way that allows me to add new features quickly and easily. My plan is to move fast with 2.0 and quickly iterate. Jen Simmons has requested Jekyll support, so that’s next on my list.

What is your favorite animal, and why is it the unicorn?

My favorite animal is the chupacabra because if the chupacabra is not your favorite animal, the chupacabra will devour your spleen.

In conclusion

Thank you very much Bryan, for taking time to do this interview. If you want to know more about him be sure to follow him on Twitter and don’t forget to check out CodeKit if you haven’t had the chance!