Why I’m flopping back to CodeKit…for now.

For the a past two years now, I’ve managed to ween my way off of GUI based software to opt for more of the “technical” CLI based way of doing all of my task running items (e.g. – compiling SASS/SCSS, minification, JS linting, etc.). Before going the command line route I was using CodeKit, which works amazingly and is a wonderful tool to help you get up, running, and compiling in no time. It really is a great app and takes all of that “playing the game before you can play the game” headache out of the whole web dev process.

But as I got more familiar with the command line and future upgrades to CodeKit came with a price tag, I took it upon myself to start using a JS based task runner instead. Why? Well for one, it makes the project more agnostic (in a sense) where if I needed to hand it off to someone else, I could just give them the files and all they would need to do is install the command line utility through node, run an npm update, and they should be off and running. But the other reason is that it seems that using a CLI based task running is, and maybe was, the more “grown-up” thing to do. To me, there was a sense of legitimacy that came with the ability to run something like Grunt for all of your web dev tasks. And that using a GUI, like CodeKit, was something that novices did. So yeah, being able to have the knowledge was something of a gold-star standard for me amongst the devs. And always messing around in the command line always seems cool when people look at whatever the hell you are doing.

So, I started with Grunt.js and that worked out pretty well for a while. Then Gulp.js came along and that was like “WHOA, this is nice…” and so I switched to that and have been using gulp to do all of my web development task running.

Lately, I’ve been working on trying to refactor the AutoFocus theme; a theme that I really enjoyed using a few years back. Just the way that the layout was and how it handled images was really elegant and I really do enjoy just how it flows with content. But it hasn’t been maintained, it’s not responsive, and needs a good overhaul for it to be pushed back out into the world again. So I decided to start refactoring it, if anything, for my own personal use.

What I didn’t realize is that when I was setting up local environment that while doing an update to my node packages I didn’t notice that I had upgraded to Gulp 4.0. Which isn’t terrible and was one of those things that I knew that I was going to have to accept. But for the sake of this being a project that I wanted to get up and running off the ground as rapidly as I could, I was starting to realize it was gonna take some more finessing to get my current gulpfile to be 4.0 compliant. I made the normal rounds of digging through Stack Overflow try to dissect the errors that Gulp was throwing at me now since the 4.0 upgrade. Made some changes here and there, but no such luck. I could get it to run, but getting it to watch after a SCSS file had changed was doing…nothing. Did some more digging. Learned more about the serial and parallel run tasks. Made some more changes. Now it’s erring out and still…nothing. More digging. Some more ideas…nothing. Tried out some gulpfile generators. One did give some hope, but it added a TON of extra modules that I would have spent more time trying to remove them than getting everything to work.

After about a good 2 hours or so, I threw in the towel, went to the CodeKit site, downloaded the app, dug up my old license key, and paid for the upgrade. There, it was done. I was back to what I knew would work and this small RPG of getting gulp to work was no more. And to be honest, the more that I think about it, the more I realize going back to CodeKit isn’t a bad thing really. I mean, overall, the repo for the AutoFocus theme is going to contain the compiled CSS overall, so it’s not like I need to have a specific complier ready to go for anyone to hand off to. So, yeah. It works and now I can get back to work again.

Is this post a personal rant and gripe about gulp? Maybe. But it begs the question, why does this have to be so damn hard just to get to doing the work that needs to be done? I do understand that using CLI based task runners are preferred for larger-scale operations. We’ve been using gulp at my current employer after we hired more devs and realized that we couldn’t support everyone’s different flavor of compiler (Scout, CodeKit, Sass Watch) so we rolled in gulp into a package and away we could go. But for smaller projects, like the AutoFocus theme, CodeKit fits the bill for it just fine. And for now, I think for all my personal projects I’m going to stick with CodeKit. Until I decide to put my “grown up” pants on again and dedicate some time to hash out the 4.0 update. But for now, I don’t want to looks focus on letting this bigger project of getting this theme squared away. So I’ll take what I can get, and right now this works.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2019 Scott Dunham . Powered by WordPress. Theme by Viva Themes.