Posts Tagged: Development

Advice for front-end developers for 2015

People who know me in the non-internet world, know that I’m prone to giving advice. I try and do it gently, and I always try to make sure I’m not preaching. My wife will absolutely disagree with that last sentence, but what do you do? The simple fact is when I find something I like, I tend to really like it and want to show everyone around me how awesome it is.

I have just two pieces of advice for front-end developers in this brand new year:

1. If you’re not already using Sass, start.

If you’re still writing plain-old css, make 2015 the year that you make the switch. If you’re using less, switch from that to Sass. This is 100% my opinion, and I mean absolutely no disrespect to the less team, but Sass really feels much, much better to me at this moment in time.

I give this advice as a long, long time writer of styles. I was actually (relatively) late to the pre-processing party, seeing it as more trouble than it was worth for a long time. When I finally saw the light and found a simple tool to do my preprocessing for me, I happened to choose less. I have no idea why now that I look back on it. Maybe it was because less was Javascript and Sass was Ruby and so it seemed easier to get started with, but no idea really. In any case, I was a preprocessing convert in literally minutes. Almost instantly, writing vanilla css seemed like a chore.

As a long-time less user, why do I recommend Sass now? I’ve really only been using Sass for just shy of a year, after several years of being quite happy with less. I actually tried Sass several times in those years, but really couldn’t see the benefit. It wasn’t until I realized that everyone I knew and followed online was using Sass that I forced myself to switch to see if I was missing out on anything. Turns out I was.

I was missing out on these 2 major things:   community and breakpoints or “named media queries”. First, in short, the Sass community is awesome and active. Have a look through The Sass Way for many examples of this. Second, breakpoints are amazing. It will change the way you write and think about media queries.

2. Start using Grunt. 

I know, I know. Grunt is weird and hard, even though Chris Coyier told you it isn’t. You still find it too developer-y, or too finicky, or too much effort than you have time for, or all kinds of other legitimate reasons. I completely understand. I tried to “get” Grunt for a long time before it finally clicked for me. But now, after just a few months, I’m quite comfortable with Grunt and hate working on projects without it.

My best advice for getting started with Grunt is this: just get it to compile your Sass for you. No more than that. Don’t worry about compiling Javascript, or minifying  or uglifying or anything else for the time being. Just get Grunt to watch and compile your Sass for you as you write it and get comfortable. If you follow that 24ways post, you shouldn’t have too much trouble getting going. If you get errors just google them and work through it. I swear it will pay off in the end. If you’re a WordPress theme developer, I’d strongly, strongly recommend using 10up’s Grunt starter theme. It’s extremely bare bones (you’ll see what I mean when you install it), but it will give you a great example of how to set things up when you get a little more familiar with Grunt. Combine the barebones setup with templates from Underscores, and you’ll be a theme master in no time.

Why? 

I was happily writing css with less for years, and before Grunt I was very happily using LiveReload to compile it for me. But Sass and Grunt are much more than a replacement for these things — they’ve opened me up to so many more tools and workflows and best practices that I didn’t even think about when I started. The Grunt ecosystem is massive — filled to the brim with useful tools for so many things that you’d want to do. But until you start to use Grunt in even a basic way (like compiling Sass), you’ll never be exposed to any of it.

These days, I use Grunt for all kinds of things: processing and minifying Sass and Javascript, making sprite maps, cross-browser testing, highlighting unused css rules, minifying images, and much more. It will become an essential tool once you get over the initial hurdle.

I’ve been pretty shy on details here because a post like this could almost turn into a book if I started going through examples and how-tos, so I’ll just end it here. I wish I’d read exactly this advice on January 1st 2014 or earlier.

ps: #1 Like most people, I actually use the scss syntax.  #2 I have no idea if it’s SASS or sass or Sass / LESS or less or Less.

Figuring out the size of folders in your Terminal

Ever wonder how big those folders are getting on your server? Your wp-uploads folders can get huge over time, and it’s hard to figure out just how huge.

Using ls -la tells you about the files, but not the folders:

terminal-ls-la

Luckily we’ve got something better. Give du -hsc * a try. It will return this pile of useful information:
terminal-du-hsc

I can now see the size of each file and folder in my current directory and I get a total at the end. Cool! The odds of you actually remembering that command in two weeks time though is probably zero, so let’s setup an alias with a better name:

  1. Log in to your server
  2. Type nano ~/.bash_profile
  3. Nano is a basic text editor. In that window add a new line: alias whatsize="du -hsc *"
  4. Save and close that file (ctrl+x)
  5. When Nano closes and you get back to the $ prompt, you’ll need to tell your shell about the new alias you just created. Do that with: source ~/.bash_profile.
  6. Last, go to a folder you want to inspect and simply type whatsize!

The Workflow here @Waterstreet (Part I)

Development workflow is an extremely personal (read: contentious) thing. Everyone has an opinion and a way that they do things, and yet we get challenged every day with a swath of new tools designed to make our development faster, easier and more productive.

I’ll just start writing and see how many I come up with: LESS, SASS, Codekit, Compass, LiveReload, Jade, HAML, Coffeescript, Stylus, SLIM, Eco, etc, etc. That’s a lot already, and its barely the tip of the iceberg. In the past few years, I’ve tried almost all of these, and here’s a few notes on what I use:

LESS

It took me a long time to finally get around to LESS. I had it all bundled together in that huge pile of stuff that I wanted to learn one day. I’m extremely glad that day come a few months ago.

LESS gives you variables, nested rules, mixins, functions, and all sorts of other goodies that I don’t use yet. Here’s a quick example of how I use LESS on a daily basis, and how it makes CSS writing easier and more enjoyable:


@mainbg: #efefef;
@maintext: #444;

#main{
  background: @mainbg;
  color: @maintext;
  float: left;
    
    a {
      color: lighten(@maintext, 5%)
      background: darken(@mainbg, 25%)
      }
    
    article {
      width: 450px;
      float: left; 
        
        h2 {
          font-size: 25px;
          color: darken(@maintext, 20%)
          }
      }
    
	}

So what have I actually used here? I’ve used LESS fairly minimally here as you can see. I declared two variables at the top: a background colour and a text colour, which I lighten and darken at various points. And I used nesting: see that H2 underneath article? of course those rules will only apply to an article’s H2. Pretty sweet. Likewise, all of those rules only apply when they’re contained in the #main div.

As you can see, none of this is a huge shift. It isn’t complicated, and after you’ve written it a few times, it actually makes more sense. It’s pretty easy to see that writing this:

article {
  width: 450px;
  float: left; 
    
    h2 {
      font-size: 25px;
      color: darken(@maintext, 20%)
      }
  }

Is a lot better than writing this:

article {
  width: 450px;
  float: left; 
	}

article h2 {
	font-size: 25px;
	color: #3f3f3f;
 	}

You can imagine that for even a small site, those style rules that nest underneath article will add up.

One last LESS benefit is the magical lesselements. I say magical because it is. Remember all those browser-specific prefixes you used to write?

#main{ 
 -webkit-border-radius: 5px
 -moz-border-radius: 5px
 -opera-border-radius: 5px
 border-radius: 5px
}

That truly is terrible to look at and onerous to write. With lesselements, all you need to do is write one rule:

#main{ 
 .border-radius(5px);
}

And lesselements automagically prints out the browser prefixes for you. And you sleep better at night.

Sounds great, but where do I start?

Good question. The best place to start is with LiveReload. Can you even come up with an estimate of how many thousand times you’ve hit Cmd+R in your development career? With LiveReload, you’re done with Cmd+R. Now, all you need to do is save the file, and your changes will magically appear in the browser window—without Cmd+R. Just reread that again if you need to. No more refreshing the browser window—just hit save and you’re done.

But that’s not all the magic that comes with LiveReload. Not by a long shot. Remember all that LESS stuff we mentioned a few minutes ago? LiveReload’s your uncle for that too.

So you’ve written some extremely cool LESS and you’re dying to get it up there on a site you’re working on. But! LESS isn’t quite as easy as CSS—LESS actually needs to be compiled before you can use it. Queue the sad panda parade.

But despair not!

All you need to do is tick off the compile button in LiveReload and it will convert (compile) your style.less file to style.css. Your website never needs to know about the LESS file, and technically never knows you’re even using LESS at all. The LESS file you write gets compiled into CSS when you hit save, and that’s all your website sees.

So that wraps up Part I. I really hope this was enough to convince you to give LESS a try. It really is better than plain-old CSS, and without all that headache and overhead you were expecting. And if you’re not yet using LiveReload, now really is the time. Since I started using it about 2 months ago, I use it all day, everyday and I can’t imagine doing without it. Cmd+R is ancient history.

In Part deux, I’ll run down how I deploy/launch sites. Spoiler: I haven’t used an FTP client in years.