9 Weeks with CodeKit 3 - A Review

Introduction

Back in January of 2015, I posted the longest continuous blob of text I had written since college, a review titled 9 months with Codekit 2: A review. It was a meditation on task management in the world of front end development. The review was popular enough to be ripped off by a few hack writers on other blogs like yourwebsitefirst.com which managed to use a verbatim copy of my review's final points. As the saying goes: Imitation is the highest form of flattery. It seems fitting that this now is officially the most longspun single article I've written for my blog edit: oh how naive I was when I wrote this, now that I have a 20,000+ word article. I'd like this review to be as accessible to novice coders and beginners as possible, but it will inevitably be more technical. To explain the differences between CodeKit 2 and 3 requires certain vernacular, vocabulary, terminology, and industry acronyms. Readers may want to revisit my previous review for context as I spend more time explaining the usefulness of a task manager and Sass.

Front End Development is wildly a caustic field to learn as every week we're talking about some hot new JS framework. It's also a wild mix of several professions including but not limited to: app developers, animators, data visualization architects, content/information architects, CMS (content management system) templaters, UX/UI designers, all residing under a very wide umbrella called front end development. The great unifier between these professions is the core technologies: we all live and die (primarily) in the browser. The primary focus is on HTML, CSS, and Javascript, even if we abstract ourselves from it with technologies like JSX, Sass, and TypeScript. I imagine in less than a decade we may see a fragmentation of front end development into perhaps two or more divisions, starting with javascript app developers. I also worry until the fissures start forming, front end web development is a hostile environment for junior developers, due to the dearth of knowledge required to be independently successful. Postulation aside, If I can bring the tiniest bit of sanity or elucidation to this review, then I'll consider this a success.

Also, this review may sound like I'm focusing on the negative (isn't that the way of 2016?), this is because CodeKit 3 is a very mature, very stable product and you probably should buy it if you like CodeKit 2 or fancy a GUI for task managing. (How's that for a review? You can essentially skip the rest of this review if you want.)

As with my previous review, I'm starting with a mini-glossary of terms and how they relate to the review below.

Mini-Glossary of Terms

command-line Interface(CLI) - A GUIless (graphical user interface) way to interact with a computer. Commands are entered and run via the terminal on a computer, for most users this is done via a BASH terminal on a Linux/Unix variant like macOS (Formerly OS X) or Ubuntu (Linux). For web development, many utilities/libraries (like Node.js and docker) require some basic terminal knowledge to use.

Compiler - A utility that transforms source code into another type of data that an operating system or program or web browser can understand.  Some languages must be compiled before they can be run and some programming languages use Just-In-Time compilers (compiling on the fly) which are languages that are not compiled until the code is executed. In regards to web development, a web browser compiles Javascript in real-time via its customized javascript compilers, and web servers run (primarily) PHP/Python/Ruby/Java/Node.js each with its own real-time compilers. There are many types of compilers and interpreters that differ wildly depending on what platform and programming language are used. When I am discussing compiling for the sake of this article, I am strictly talking about compiling the code with a preprocessor in order to spit out code in common web languages that are read by a web browser.

Preprocessor - a utility that processes and converts one type of data into another type of data that another program can use. Preprocessors are not compilers, but when they process code, is often referred to as "compiling.&quot For the sanity of this article, I will refer to the action of "compiling" exclusively within the context of preprocessing. Compiling is often used as a blanket term for programming languages that require processing for the code to be a browser readable language. Sass, Less, and TypeScript are often referred to as preprocessor languages.

Syntactic sugar - Syntax in a programming language that is designed to make things easier to read and understand. However, the end result of syntactic sugar does not affect the core ability of the language. Example: Sass, LESS, JADE and TypeScript's most primary function is to provide syntactic sugar to CSS (Sass/LESS), HTML (JADE), and TypeScript(Javascript), nevertheless there is some argument to referring to them as purely syntactic sugar. While jQuery is a robust library, it's a large part of the value it adds is still syntactic sugar by reducing the number of lines of  javascript code to more human-readable code.

Linting - a utility that runs to check code for potential errors and/or enforce coding style guidelines. Linters exist for almost every programming language.

Task Manager / Task Runner - a program that once configured, can automatically perform common/routine tasks. Task managers can “listen” for events and automatically run a series of instructions based on event parameters. For web development, this usually means when a file is saved, or project structure is altered, or a specific command is entered into the CLI. These events trigger a series of actions such as initiating a preprocessor to compile code, followed by  refreshing a page. Popular task managers include:

• CodeKit - A Mac-only utility with a graphical user interface
• Prepros - A cross-platform utility with a graphical user interface
• Gulp.js - a command-line utility built on Node.JS + Node Package Manager (NPM) built on Node Streams (asynchronous data flows) via 'pipelines.'
• Grunt.js - A command-line utility built on node.js + Node Package Manager (NPM). Predates Gulp.

Gulp, Grunt, and Webpack are open-source command-line utilities that allow you to execute custom code or functions in other utilities to compile / minify / uglify / concatenate, pre-compiler languages such as Sass and TypeScript automatically each time you hit save. This is hardly all they can do. Both can be configured to use popular plugins like BrowserSync, a server wrapper that acts as a middleman to live-inject CSS changes and reload when various files are changed like HTML/PHP/Python/JS/JSON files and synch mouse clicks/scrolls across multiple browsers. They can be configured to do auto vendor prefixing for CSS, remove unused CSS, optimize CSS to shorthand, image optimization, image resizing, SVG minification, SVG merging, create custom builds of libraries like Modernizr, perform Linting, use Unit Test libs, create basic style guides, generate CSS icons, move files/folders, rename files and folders, zip files/folders, search and replace strings, and even integrate with Google PageSpeed analytics, create screenshots and monitor file sizes. These events can be chained together in any combination that one sees fit. Developers are free to create their own utilities to run within task managers.

That's quite a list of things that can be automated, and sadly both Gulp and Grunt aren't the most forgiving utilities for those new to web development (Webpack even less so). They can be cumbersome or annoying to set up for developers who are in a turn-and-burn environment where project timelines do not account much time for tooling/setup. Most seasoned devs using Gulp/Grunt (self-included) have a template that they use to configure with several favorite tasks easily, and call it a day.

DOM  (Document Object Model) - As a front end web developer: This is your life. Think of it as the rendered version of your HTML/CSS/JS.  A good cliff notes introduction to the DOM is the CSStricks article, "What is the DOM?". Web browsers have the ability to expose the DOM structure via developer tools such as "Inspect Element."

Package Manager - a package manager, automates the process of installing, upgrading, configuring, and removing software, and the respective dependencies. This term often refers to package managers used by operating systems, but for the sake of this review, I will be only using this term for web0centric package managers. Node Package Manager and Bower are the most popular package managers for front end developers. When a project requires installing libraries to run, these often are referred to as "dependencies." However, Bower and Node are not dependency managers. node.js is much more than a package manager.

Watch - Task Managers have the ability to "watch" files. When files are watched, this means when a file is changed on the watch list, it can trigger an event such as compile sass, compile javascript, copy files, run image processing and so forth. This is probably the most common task for task managers.

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 core instructions that your browser needs to render the page, this will help aid page load speeds considerably.

Concatenation - (concat for short ) when programming means combining 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 number of requests a web browser must make, and thus (usually) speeds up the data transaction from the web server and reduces the load on the webserver.

This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.

Auto-prefixing - Browsers often add features before they're an official CSS spec. The supported-but-not-official specification features would require a vendor prefix like -webkit-font-smoothing or for Firefox, -moz-osx-font-smoothing. Keeping track of these is a pain. Depending on your support configuration, writing a simple gradient such as:  

background: linear-gradient(to bottom, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%)

Will also generate all the browser prefixed code such as:

background: -moz-linear-gradient(top, rgba(30,87,153,1) 0%, rgba(125,185,232,1) 100%);
background: -webkit-linear-gradient(top, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%);
background: linear-gradient(to bottom, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%);
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 )

This will ensure your code will work on older browsers that require prefixes and prepare for the day when prefixes aren't needed. This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. Also, prefixing may become a thing of the past one day, as webkit announced that it was doing away with prefixes.

SVG - Scalable Vector Graphics Format (based on XML) is the preferred vector format of the web. While I expect anyone who is reading this to be familiar with them. It's important to understand the flexibility of SVGs. They can be written directly in HTML, in CSS using data URI, or within an image file making them unusually flexible. SVGs also can contain CSS and CSS media queries and in some scenarios, even Javascript. SVGs attributes like fill colors or stroke widths also can be manipulated via CSS or Javascript. A good way to think of SVG is a visual language describing shapes with XML and math to browsers. Vector images are incredible in the age of ultra-high-density displays as they will always render to the ideal resolution. SVGs are also the preferred image format for data-visualization as they can be drawn using javascript libraries like D3.js. For those unfamiliar with the differences between vector and raster, I recommend taking a second to read an article such as designshake.net's Raster vs. Vector: What do I use?

Sass - Syntactically Awesome Style Sheets. If you are still writing vanilla CSS, you really should stop and start using Sass. It's more or less assumed today that developers are using Sass (or at least LESS).

This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. If you'd like a quick explanation of why you should be using Sass, please visit my original CodeKit 2 review or visit an article such as Scotch.io - Getting started with Sass.

LESS - An alternative to Sass, and syntactically is very similar. LESS's primary user base tends to be asp.net developers.

Stylus - An alternative to Sass, the least popular of the major three CSS preprocessors. Unlike Sass and LESS, it makes use of whitespaces, making it the most unique of the three.

Source map - If you inspect-element and use a minified CSS file, it can be a pain to track down what line of code that the original CSS originates from as everyone is on one line without spaces. Source Maps are ancillary files generated to map where the original contents of a line of code reside in the original CSS and javascript files. Once a browser is configured to use source maps, JS console errors will display the line of the code based on the non-minified / uglified files, and CSS references will display where the original CSS originates, down to the line of the appropriate .scss file.

This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.

Bless - A lesser-known bug in Internet Explorer which causes CSS to be completely ignored after the limit of selectors allowed in a single CSS file is reached. Bless provides a simple solution: parse the CSS file into multiple files. See blesscss.com for more details.

BrowserSync - an open-source application that allows for synchronized browser testing, and the ability to manipulate the page in real-time via code injection. The most common use is pairing with Gulp or Grunt and used to trigger browser reloads on code changes or live CSS code injections after a task manager detects the CSS file has been altered. This allows the browser to seamlessly change the layouts in near real-time or trigger page refreshes on HTML/PHP/Python/JS/etc changes when properly configured. It even allows the user to pair page interactions to multiple devices. If a user clicks on a menu in one browser, the same menu will be opened in all other browsers that are using the BrowserSync web server. It's rather magical to click a link on an iPhone and see both the desktop browsers and the iPhone load the requested page. If that weren't enough, BrowserSync also features remote device inspect element by using the JS library Wienre. Wienre gets several mentions on this page because it can be a massive time saver for extreme edge case browsers that do not have the ability to inspect element. For more info, visit browsersync.io. There are few utilities that make my life easier on a daily basis than BrowserSync + Sass.

This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.... (you get the idea)

About My Workflow

It's always interesting to consider how my workflow has evolved since my last review as a lot can change in 2 years. When I wrote my CodeKit 2 review, I was still using Sublime Text, and my day-to-day task manager of choice was Grunt on a RAM/Storage starved MacBook Pro Retina 2013 (8GB of RAM/256GB SSD). Most of the projects were CMS sites that were coming through the door. Today, I'm using Grunt and Gulp, Atom, working on CMS sites, and Cordova (PhoneGap) apps. OS X is still my platform of choice, and my company bought me a shiny MacBook Pro Retina 2015 (16 GB of RAM/Dedicated GPU/512 GB SSD). The suite of my other tools hasn't changed much: iOS Simulator and GenyMotion are my go-to's for simulators. I still use Parallels and sometimes VMWare for IE. Sketch is my world, so is Photoshop, and I'm starting to play with Principle for interaction design. Tower is my Git client of choice, and Kaleidoscope is my show-diff/merge tool, and Grunt/Gulp are my task managers of choice. A few other utilities I lean on are ColorSnapper, ImageAlpha, ImageOptim, Xscope. I do JS, but I'm still bolstering up on major frameworks. I remember life before CSS, the transition with absurd workarounds and even have toyed with postCSS. Also, my job has evolved as I'm more client-facing than ever. I mention all of this as not some sort of a humblebrag but because every front end developer's job currently encapsulates many practices: Interaction Design, Graphic Design, Web Accessibility, Javascript application development, User Testing, Data Visualization and so on. What my daily workflow looks like could be wildly different than someone else who wears the same job title as me. I have yet to write unit tests, but someone reading this review might spend a bulk of her day testing code. My job inevitably will be not an accurate representation of front end development as a whole, just a segment. Use this information to compare and contrast as my needs will be inevitably different than yours.

What is CodeKit?

By now hopefully, you understand that CodeKit is a task manager with a GUI, designed primarily to compile various preprocessor languages. These languages include: Sass, Less, Stylus, JavaScript, CoffeeScript, TypeScript, Pug (Jade), Haml, Slim, Kit, Markdown, and JSON. It also comes pre-baked with support for the following frameworks / libraries: Bourbon, Bourbon Neat, Bitters, Zurb Foundation, Google Web Starter Kit, Susy, Nib, Jeet, and Compass. This isn't to say that these are all that CodeKit is compatible with, but rather simple ones that can be quickly installed via CodeKit. Codekit can even support more languages using its hooks system to initiate CLI processes to keep all your tasks primarily within the GUI.

Simply put: Everything that CodeKit does can be performed by Grunt or Gulp. What you're paying for is a refined GUI for extremely quick and nimble setup and a much lower learning curve. Even as a seasoned dev, I'll admit that I can get rolling with CodeKit within less time than with my grunt or gulp starter templates. CodeKit's primary value is that it lowers the barrier to coding, and cuts out some of the initial setup. Drag and drop your project in, then create a few paths for where compiled files go and which get concatenated, and you're back to your IDE. CodeKit isn't aiming to replace all complex tasks for edge cases that Gulp and Grunt can do but rather all the common ones. It's designed to be the daily warrior, akin to my favored task setup in my grunt and gulp template files.

For less seasoned devs, CodeKit is indispensable. While I'd argue eventually it's a good idea to familiarize yourself with a CLI task manager, the front end developer pool is a deep one to jump into headfirst. There's decades of tacit skills, like IE or Safari hacks (browser testing / device compatibility), learning how to vertically align things with CSS (this is still a problem even though CSS's W3C Recommendation dates back to December 1996), how to leverage ES6, learning the ins-and-outs of a syntactic sugar preprocessor, what new hot JS framework is bringing all the devs to HackerNews, and so on. The state of front end development is a precarious one, so anything that frees mental space for concentrating on core tasks is welcomed. This is where CodeKit truly shines.

What's New

First and foremost, CodeKit got a facelift... if you can call it that. It's gone hyper-minimalist to the point of abstraction or undesign. I found Codekit 2's "look" pleasing even if the interface was occasionally bumpy. I can't say I'm a fan of the new GUI. I also was not a fan of Yosemite's design or iOS 7's design. Both took several iterations to strike a balance between minimalism and design and I'm hoping perhaps CodeKit 3 will follow this trend of slash and burn and then replanting. Almost all text has been removed such as "Server," "Preview," "Assets". Even worse, a mouse hover doesn't bring up any tooltip explanation. Instead, you're left with "Click and hope for the best." When I first was writing this review, I initially missed CodeKit 3's package manager leading me to believe it had been removed. It took accidentally clicking on it to realize it was still there. It's not a great start for a utility that's value is explicitly that it is easier to use than a CLI. The redesign is not a total loss: there's a nice project overview that also includes a build project button so builds can be triggered manually.

That said, any caveats with CodeKit 3 are minor seeing as the primary function of a task manager is to operate silently in the background until something triggers it to take action (usually hitting save on a file). The real changes are under-the-hood.  The full list is on CodeKit's website, but I'll highlight what I think are the most important new features. Don't worry if you're unsure what the differences are as I'll break it down later in the review.

• Build System: Trigger builds from UI. Project migration
• Image Optimization: SVG optimization, gif optimization. Better optimization engine for PNG/JPG.
• Javascript: Babel transpiling and babelrc support, React compiling, ESLint and eslintrc support, 
• Server: Simple SSL Support
• Hooks: Matching support with RegEx, per file triggering, hook error logging
• Custom Language Support: Add Your own languages and combine with hooks
• Bower: Creates/updates bower.json, version support for components, rename/relocate bower folders
• CSS: Bless, auto-prefixing, Minification, Source mapping (for shits and giggles I suppose) for regular CSS files
• Other: Bitters framework support, Pug: Jade's successor with backward compatibility for Jade

My Wishlist from late 2014

For fun, let's compare CodeKit 3 to my late 2013 wishlist of features found in my CodeKit 2 review.

• 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

So of all the features other than my pie-in-sky dream of Grunt/Gulp pairing, all but one of my requests were addressed.  Did Bryan Jones read them? Probably not, these were pretty reasonable and likely obvious feature requests. The best it can affirm is that I am a front end developer who has enough technical prowess to know there are thoughtful features that would make my life easier. I stress reasonably because I could wish for a "make website better button" but its insanely non-specific. 

Overall I'm pretty happy that all but one target was hit. I'm still surprised that CodeKit doesn't have a remote element inspection mostly because it doesn't seem to use browsersync. BrowserSync has the ability to use Weinre, and track user interactions to pair across multiple browsers. As near as I can tell is it's a custom WebSockets configged server. Perhaps one day, CodeKit 3 may switch to BrowserSync.

Code Compiling

CodeKit's primary function is compiling code. If you've used CodeKit 2, then configuring CodeKit 3 is pretty much the same process. CodeKit will read imports in JS/SCSS/LESS etc, but the initial pathing is set up via the UI. CodeKit 2 never was perfect about making sense of project pathing, and CodeKit 3 makes no more attempts to improve it. It'd be helpful to see an overview of sorts to know what files are outputting to where at a glance. That said, it's no less esoteric than reading JSON config files. All linked files can be viewed from a master file but without any pathing info nor can listed files be right-clicked to "show in finder" or "open in an editor.".

All the front end coding greatest hits are here: concatenation, minification, source map, auto-prefixing, and blessing.

Compiling is as fast as Gulp or Grunt, as the compilers in CodeKit are built around the same open-source software. Without a technical way to benchmark, the best I can say is it feels as zippy as I'm accustomed to with Gulp. Compiling Sass can differ widely based on any number of factors like the apparent complexity of a project, how bogged down your computer is, and so on. What I can say with certainty is CodeKit idles well. Grunt taxes the CPU even when just watching files. Gulp seems to be much better at this and (to me personally) and marks the largest difference between gulp vs. grunt (despite all the hype around Gulp's asynchronous abilities). CodeKit seems right in line with Gulp.

Builds are triggered by hitting "save" on a watched file or via hooks, and hooks can be set to trigger other actions. If you're adventurous, you could configure  CodeKit on a save to copy files to an FTP.

CodeKit also comes preconfigured to refresh the page on HTML/PHP/Python/JS/Pug etc saves and to inject CSS without page reloads. If you're still in the old world of manually page refreshing, you'll wonder how you lived before code injection and auto-page refreshes.

CodeKit can also sort JSON content to be organized, and this can be triggered on file changes so you can always have alphabetized JSON files.

Lastly, like any good code compiler, the error log is the main event. More than likely, almost all your time in CodeKit will be spent in the error log. It's presented in a single pane, cleanly formatted. Successful builds are marked in green dots and bad in red. It's simple and effective and now has the ability to consolidate external compilers to the error log, which was to some ire of me before when I switched my Sass compiler to a newer version rather than waiting for a CodeKit 2 update.

Internal Server

If you've used CodeKit 2's server, it now has SSL provisioning and event syncing. I never knew or noticed the SSL issue since all my development is done locally, but I imagine for some this is a crucial fix. Calling CodeKit's internal server, a "server" may be misleading. Akin to BrowserSync, it's a simple wrapper that can be mapped to any domain or directory and injects the necessary JS to trigger page refreshes and CSS injection.

CodeKit now features event syncing for any page clicks, forms, and scrolls. This is incredibly useful for testing multiple browsers and devices simultaneously. This is a big addition.

As mentioned previously, Wienre allows for remote inspect element. This may not seem like a killer feature as Android and iOS offer remote device inspect element via using a desktop browser to run inspect element on a physical device connected via USB or simulators. Occasionally as a Front End Developer, you may be asked to test on an esoteric browser like Amazon's Kindle's Silk which doesn't have Chrome or Safari device inspection. Wienre is the answer.

CodeKit's Servers works well for a wide variety of projects and even integrates with MAMP.

Image Optimization

Saving an image from most image programs is not the most data-efficient use of a file format. Often they bundle in metadata and do not use obsession-tuning that makes the most use of compression, optimization techniques. For JPEGs and PNGs, there's a set of algorithms that optimize images and can shave significant amounts of data off them without affecting the image quality. Since these require zero input from the user other than what files to target, its a painless way to shave significant amounts of data off file sizes.

CodeKit's image optimization got a much needed revamp. Prior, image optimization worked but had some serious caveats. Edit: April 10, 2017. CodeKit now folds in ImageOptim's incredibly powerful image optimization algorithms. It's technically a lossy encoder but virtually unnoticeable (I haven't ever noticed it). While ImageOptim is free, this means one less thing you need to use. CodeKit now is the best of the best when it comes to auto-optimization (better than Grunt or Gulp). Notably, this isn't the same as treating a PNG image manually using ImageAlpha. Codekit 3 launched with much-revamped image optimization, prior it did not have any SVG minification support. Prior to the addition of ImageOptim, In my tests of a 4.1 MB PNG, both ImageOptim and CodeKit 3 produced a 2.6 MB PNG file. CodeKit 2 produced a 3.1 MB image. Results will vary wildly based on the individual image. Also, Codekit 3 can be tuned to also watch files to recompress on a file change unlike CodeKit 2.

See the Pen CodeKit SVG Optimization by Greg Gant (@fuzzywalrus) on CodePen.

SVGs, as described in my glossary are essentially XML files. This means a set of tricks like minification and uglification can be used to reduce file sizes. Sketch and Illustrator created SVGs that contain a lot of extra data and are not minified by default. The process of SVG optimization is much more akin to Javascript optimization than PNG/JPEG optimization. Clicking on an SVG gives a host of options, all from the SVGgo library, a set of SVG specific optimizations. SVGs can be set to copy to other locations leaving the originals unaltered.

I'm quite fond of this and CodeKit provides the best quick UI for SVG optimization I know of. This is a tremendous win for CodeKit.

About the only thing CodeKit doesn't do is export inline SVGs or crunch all SVGs into a single SVG file, which are edge case optimizations. I guess for the truly ambitious this is obtainable, but this is pure speculation as I haven't had time to mess with hooks.

In future releases, I'd like to see CodeKit go beyond simple optimization, specifically creating sets of resized images based on rules for responsive images. The would take some careful consideration to deliver a simple solution, but I'd love to create image sets from an original source image easily. Perhaps that's a sister utility waiting to happen for CodeKit? I'm not sure...

Package Management

Codekit 2 made an admirable attempt to bring package management to CodeKit, although I always found it a little confusing. CodeKit 3 is still no different, and the interface isn't entirely great. It's hyper-minimal and allows for a set of favorite components, and the ability to search for new ones. Unfortunately, the search bar is hidden and takes poking around to find.

CodeKit offers easy installs for a few well-used add-ons (Bourbon, Bourbon Neat, Bitters, Compass, Zurb Foundation, Susy, Nib, and Web Starter Kit) via the project preferences pane. CodeKit also offers Bower support and can read bower.json files to install dependencies. I'm unsure if CodeKit can use .bowerrc configs and I plan to test this when I have time.

CodeKit also offers the ability to create your own framework of commonly used files as before. I can't say I personally like CodeKit's package manager as I found it easier to simply search and find the frameworks or plugins I was looking for via google and installing them (via bower or node or manually) than the guess and check method of CodeKit. I do like the Bower config file support as even junior devs can understand the bower.json after a little bit of reading.

CodeKit doesn't offer package.json support for NPM (node package manager). Deal-breaker? Not at all, but it is a nice-to-have feature to make CodeKit all-encompassing.

Hooks

CodeKit 3's hooks allow you to tap into the underpinnings of your computer, as CodeKit 3 supports Bash scripts and Apple Scripts. Bash scripts allow you do infinitely powerful things, for example, I wired up CodeKit to ImageMagick to create JPEG 2000 and WebP images from PNGs. Rather than post an elongated how-to mid review, I've created a tutorial on how to do it. Admittedly this is scratching the surface.

Hooks this tiny script will create JPEG2000 and WebP images from PNG files when PNGs are modified.

CodeKit 3 easily could be set to watch your npm package.json file and when modified, run NPM install to keep packages up to date or upload image assets to a CDN when modified. The possibilities are as far-flung as CLI task managers with some minor caveats: Hooks cannot be interactive and require inputs.

This gives CodeKit much more versatility than what CodeKit ships with out of the box. As someone who uses Bash daily but not a prolific scripter, if you're a terminal junkie, your imagination probably is greater than mine.

The CLI task managers vs CodeKit 3

Gulp as exciting as it gets

Both Grunt and Gulp are immensely powerful. As I was working on transitioning a Cordova project to Gulp after using CodeKit 3, I was debating if I wanted to try out a plugin to auto-generate a style guide and to delete unused CSS. The last project, I created a customized Modernizr build based on scanning my CSS file for modernizr classes using a grunt task. Grunt and Gulp have amazing support, and it shows, but the setup is intensely unfriendly. It'd be easy for me to go "greybeard" and detest kids and their GUIs, but they have their place.

How much is a clean and easy to use GUI worth? This is the most prescient existential question to CodeKit. It'd be easy to say not much or launch into a tirade about the superiority of Gulp but this for years was at the very crux of Apple's OS X as it was Unix but dressed up and cleaned for day-to-day use. This isn't the best analogy, and we have better analogs to CodeKit 3.

CodeKit does for task management as what Tower does for Git; provide a GUI to CLI utilities. Even as a world weary-web developer, I still live by Tower. Tower can't do all things that Git does, but it does enough and makes it digestible enough where I rarely use Git via the command-line. The only time I can really recall CLI Git in the past year was for git resets and nuking a branch. CodeKit can do the same, albeit with a few more limitations. (Tower recreates the functionality Git whereas CodeKit recreates the functionality of a plethora of utilities)

CodeKit does something that I find valuable: it gets me to writing code more quickly. My personal portfolio always has been managed by CodeKit, and even when I start projects and need to code something up rapidly, I tend to lean on CodeKit. It reminds me of my early days as a digital musician. I learned to use Reason 1.0 in the year 2000. Reason was novel since it was immensely easy to spin up and start making music with minimal delay. Around 2004, I outgrew it and switched to Cubase and but I still pine for the simplicity of Reason in which project setup was a lot faster and took a lot less overhead. It wasn't as powerful, but it got my idea out much more quickly. It's also why I still use Apple Motion despite Adobe After Effects being superior. That's the niché of CodeKit to me today.

More importantly, CodeKit allows junior developers to focus on learning Javascript, CSS, HTML, and/or any other preprocessor language without struggling through esoteric configuration. If you're already using Gulp and/or Grunt, CodeKit might be a tougher sell. For those looking to jump into front end development, CodeKit lowers the hurdle of learning modern development where automation of tasks has become integral.

Depending on your job needs or workflow, CodeKit may be all you ever need, or you may quickly outgrow it (and anything in between). This is a question I cannot answer for you, but I can say that CodeKit can be useful even to an accomplished developer.

CodeKit 3 vs. Prepros 6

Prepros (to my knowledge) is still the only competitor to CodeKit. Prepros offers a very similar feature set.

Languages:

Features:

Absolutely the biggest difference between Prepros and CodeKit is, CodeKit is macOS / OS X only. Prepros also offers Wienre support, which is nice, and a built-in FTP. For most people in production environments, the later isn't really useful, as you should be using staging servers managed by a utility like Jenkins. (but that's another story)

I wrote a review on Prepros 5 that's still pretty relevant to Prepros 6 that's worth reading as I break down the superiority of CodeKit in detail. If you're a Windows user, you can effectively stop reading this review as CodeKit is OS X only or consider getting a Mac to run CodeKit. This isn't a slight against Windows as Microsoft has made some serious sweeping changes to allow Bash in Windows, which means no longer the dissonance of trying to use frameworks like node.js on Windows which required a special Node CLI. You'll be hard-pressed to find Windows front end developers, but I assure you, they're out there and perhaps reading this review.

OS X users (excuse me, macOS) users have the agency of choice between Prepros vs. CodeKit, but Codekit is the clear winner. Codekit's ability to use external compilers saved the day on a few projects in the past for me. When I was working on a project that required a newer version of LibSass than CodeKit offered, I simply changed the engine to use the latest compiler instead of waiting for an update. Prepros does not have this ability. Also, Prepros doesn't have the nice framework library bundling, nor SVG optimization, ability to create hooks, create custom frameworks and is a little more CPU heavy.

CodeKit still leads the race, although Prepros has improved its javascript support. I also mildly prefer Prepros's UI after Codekit's redesign. CodeKit 3 allows you to grow more than Prepros and that's exceptionally important as you'll always be in a grind to automate your workflow as a developer. Prepros isn't bad; it's just not as good as CodeKit. The simple answer is if you're comparing CodeKit vs. Prepros, CodeKit 3 wins.

Looking forward: Where do we go from here?

I made some pretty bold feature requests back in 2014, and to my surprise, most were answered. So what would I like CodeKit to do in the future? This is tricky as some useful features like SVG-to-WebFonts have a limited shelf life, as webfonts are bad for accessibility.

• Single-click install dependencies for new projects (including node)
• BrowserSync to replace the current server or something nearing its functionality
• HTML minification
• Responsive image processing (auto-generate different image sizes based on parameters)
• Pie in the sky: Visual Regression Testing or jsDoc (auto-documentation generation), TMI (too many images) reporting and/or PSI (Page speed analytics)

Are these the best features? Perhaps, perhaps not. I'm not as confident with my asks as I was in late 2014. This may be a case of the Aristotelian principle: "The more you know, the more you know you don't know" but I think the easy-fixes are mostly done. We're starting to get to more avant-garde features as Front End Development itself becomes more avant-garde. I'll probably have some more insight as I started my venture into the world of React in 2017.

After jumping into React first Gulp then Webpack, I'm not sure where CodeKit 3 can exist in a framework centric flow. Webpack's killer feature is the ability inject code while maintaining states. For those who aren't using React, this means hitting save will keep all the components in the same state (forms, views, whatever) while the browser refreshes with the latest JS. While I haven't tried it, I assume CodeKit's babel support works with ES6 imports and JSX markup, thus could conceivably compile React and mimick a Gulp React workflow. Gulp and React aren't the smoothest, as every save requires a full recompile and thus zeros out any states on-screen that only stored in active memory. I quickly abandoned Gulp for Webpack and haven't looked back. I'll be honest and admit I didn't really understand Webpack and had a hell of a time getting it configged so if anyone brings sanity to webpack, I'd probably throw money at them. React/Angular probably are going to warrant specific tooling that CodeKit just cannot support for the foreseeable future. CodeKit may evolve as these frameworks mature, to support them better.

Final Thoughts:

Pros:

• CodeKit 3 is a logical step forward, and almost all the things I wanted from CodeKit 2 are in 3.
• Backward compatible
• Improved server now offers event syncing
• More languages and more JS centric features
• Much improved image optimization
• External processors and hooks
• ImageOptim's super awesome PNG compression!
• More build configuration
• Less resource-intensive than Grunt when idling
• Seems a bit faster
• CodeKit 2 users get CodeKit 3 (sans new features) for free

Cons

• New GUI obfuscates features in nebulous icons and suffers for it
• If you're on a CLI task manager, not a hugely compelling reason to use CodeKit
• Must make current project active (Only watches one project at a time)
• Even after weeks of use, still not a fan of the UI update

CodeKit is the beginning and end as far as GUI task managers go. It's quick. It's powerful. It lowers the learning curve for preprocessor languages like sass, typescript, and even babel (a little). It's $35 for a first-time buyer and offers upgrade pricing. CodeKit 2 users can continue using CodeKit 3 but only with the CodeKit 2 feature set. It's a nice gesture for long-term support, and users can upgrade at any time. Currently, the paid upgrade pattern for CodeKit is once every two years, so you can expect around two years of support for $35 and then upgrade pricing. CodeKit 2 had a lot of bug fixes and mild improvements over time. At launch CodeKit 2 didn't have Bless or auto-prefixing, which came in version 2.1.9 for compass projects or sourcemaps for stylus until 2.1.4. There are probably more features that are bound to hit CodeKit 3 that aren't on this list.

Edit: As if to prove my point, CodeKit 3 added ImageOptim to its codebase for PNG optimization. That's a helluva a feature addition. CodeKit 2 aged like a fine wine imperial stout with the frequency of updates. CodeKit 3 looks to be the same.

Edit: Hello from mid 2019, Codekit is still being updated. It uses TerserJS for minification now, Target Browsers to make sure your project will work within your selected browsers, Babel 7 support, Auto-Pause File-watching when a version control app becomes active (stopping the battles between merges and compiles), CoffeeScript 2.0 support, 10.15 Catalina support and so on. Anyone who bought CodeKit has enjoyed a steady stream of meaningful updates. A+

If you outgrow CodeKit, chances are you'll still consider it money well spent.

Versions Review

3.0.1 to 3.1

Price:  $35 first-time purchase.

codekitapp.com

Fun fact: After writing 11,000 words in three reviews between CodeKit 2, Prepros 5 and Codekit 4, I've written 42 pages single spaced or 84 pages now on GUI task managers for Front end development. This review isn't finalized, but I wanted to get this up ASAP, spelling errors, bad grammar and all.

12/21/16 update: Minor editing / grammar fixing, a lot more reference links, trimmed down intro.

12/23/16 update: Minor editing still, (a little list rambling, a little more content), better Prepros vs Codekit breakdown, error correction about event syncing

4/10/17 update: Added information about CodeKit's addition of ImageOptim and thoughts on frameworks + CodeKit.

5/12/17 update: Minor copy editing, added definitions for Style, Less, and Linting

8/17/17 update: Finally added review notes to Hooks

10/10/17 update: Minor proof update

08/25/19 update: Noticed render error on Prepros vs Codekit, fixed. Copy editing, (typos, commas, hyphens)