As web developers go, I’m a pragmatist. I have a core set of development practices that work well for me, and I’m not constantly bounding forward to the bleeding edge of dev technology.
If you’re like me, you may feel intimidated by what I’ll refer to as “die-hard” developers—devs who are innately fascinated by development languages, patterns, and tools, particularly new ones. Watching the endless flood of new tools year after year (Grunt? Node.js?) can feel like falling further and further behind the “real” programmers.
The test of a new tool. . .
My advice for this situation is not to hide from new knowledge, or to rush into it, but to investigate exactly what you’ll have to put into, and get out of, learning a given tool. In other words: How is the new thing better than what you’re currently doing, and how steep is the learning curve to make the switch? If the benefits of using the tool outweigh the costs of learning it, then go for it! If not, it’s best to wait for the tool to get more useful or more intuitive, or for something better to come along.
. . .And three tools that pass it
The remainder of this article looks at three development tools that I personally love:
Each one of these tools—Sass, local development, and Git—really does make my life as a WordPress developer much easier. I’ll walk through each one with the idea that I’m pitching to pragmatists, like myself.
For each tool, I’ll try to explain the problems with the default it replaces, how the tool helps, and what you’ll need to understand to implement it.
1. Sass: The CSS preprocessor from heaven
THE DEFAULT: CSS
The default is, quite simply, CSS. CSS has two problems:
- It forces you to repeat yourself.
- It’s static.
I go into these issues in more depth in a recent post I’ve written, but here I’ll try to summarize them briefly.
Repetitive
For repetition, first look at the following markup:
.container { background: #fff; }
.container .box { background: #eee; }
.container .box .link { color: #333; }
Notice a lot of repetition? These styles are all properly related in a way that CSS simply isn’t able to capture, because every CSS style stands completely alone.
Static
CSS is also basically static, or unprogrammable. Let’s look at why that’s a problem:
.small-rounded-square {
height: 16px;
width: 16px;
border: 1px #333 solid;
border-radius: 1px;
}
.medium-rounded-square {
height: 32px;
width: 32px;
border: 2px #333 solid;
border-radius: 2px;
}
.large-rounded-square {
height: 48px;
width: 48px;
border: 3px #333 solid;
border-radius: 3px;
}
This also seems pretty repetitive, right? It’s not literally repetition, though, because every CSS styling rule is different from every other one. What’s predictable and repetitive is the relationships between styling rules. Unfortunately, CSS is static: It has neither variables nor functions that can use them, so it has no way to map the kinds of relationships that we see above.
THE FIX: SASS
DRY
Relative to CSS, Sass is extremely DRY (“don’t repeat yourself”). Sass solves the “Repetitive” example above as follows:
.container { background: #fff;
.box { background: #eee;
.link { color: #333; }
}
}
That’s much better, right? Sass has nesting, which lets us really clarify the relationships between CSS selectors, and cuts down on needless repetition. The Sass markup above will compile to the longer CSS, so your browser won’t know the difference.
Dynamic
Here’s how Sass might handle the “Static” example above:
@mixin rounded-square($side: 16px) {
width: $side;
height: $side;
border: $side/16 #333 solid;
border-radius: $side/16;
}
.small-rounded-square {
@include rounded-square;
}
.medium-rounded-square {
@include rounded-square(32px);
}
.large-rounded-square {
@include rounded-square(48px);
}
Without getting too technical, here are a couple of keys to reading the above:
- Anything with a $ before it is a variable.
- A mixin is a styling template, and it can take variables as arguments, just like a PHP or JavaScript function could.
- How you invoke a mixin is with the command @include.
One major advantage of this setup is that you centralize repeated relationships into one place, which is again much DRYer than CSS. Let’s say we want to give our squares dashed instead of solid borders: now we just change that once, instead of three times, and all our squares inherit that style.
Or let’s say your theme uses color #EF5223 (a dark orange) really often. Do you really want to write out that color hundreds of times in your CSS markup? It’s much better to centralize it into a single variable, $main-highlight-color, which you use across the theme. Then if you want the theme to be mostly blue instead of orange, you only have to change it in one place.
Another huge advantage of dynamic styling is that you can do things with variables. As you can see, the squares’ border-radius is set to be 1/16 of their width—a logical relationship that could hold across any width, and which we never have to manually define.
As another example, if you want to lighten your dark orange slightly to make it a better background for text, you don’t have to calculate new color values with some color software package—you just do background: darken($main-highlight-color, 10%). Again, this will still work even if you change everything from orange to blue. None of this is available in static CSS.
GETTING STARTED WITH SASS
Here are some tools on the basics of the Sass language:
- Sass and WordPress: A Love Story, by yours truly. Covers Sass’s role within WordPress and gives advice on getting started.
- Sass Basics: The official Sass documentation. A great place to start understanding the what, why, and how of Sass.
- “How To Use Sass With WordPress–A Step By Step Guide”: A general tutorial on Sass and WordPress. Includes Ruby command-line tutorials and a list of Sass compilers.
- “Sass for WordPress Developers”: A lot about organizing your Sass into separate partials, and about compiling Sass. Also has a list of tutorial resources at the bottom, to add some nice recursive-Sass-tutorial-link depth.
- “A Guide to learning Sass in 20 minutes or less“: An introductory tutorial on how to get started using Sass with WordPress.
Sass compilers
Perhaps the biggest obstacle to getting started in Sass is figuring out how to compile it — meaning how to programmatically turn it into the CSS that a browser understands.
The standard way is via command line, but if that’s too intimidating for you, there are some GUI-based compilers that make the process a lot less technical. The one I’ve tried is called Koala. It works great in Windows, and claims to do the same in Mac and Linux, as well.
2. Local development: Go away, Internet
THE DEFAULT: REMOTE “DEV” ENVIRONMENTS
In general, to see how a change to a website looks, you have to put the change online and navigate to it with a browser. The default for this is the following process:
- Save edited file
- Upload local file to remote server via FTP, overwriting the current version, if necessary
- Reload browser tab to see new version of file
This is less than ideal for a ton of reasons, including, in no particular order:
- Someone has to pay for the hosting
- You have to be wary of both server- and browser-side caching
- You’re manually syncing two versions of a file, allowing for all sorts of mistakes
- A teammate with FTP access to the site can accidentally overwrite or otherwise ruin your work
- If you fail to take precautions your dev site can be seen by unwanted visitors, draw SEO juice away from the live site, etc.
- You can’t do development at all without a steady internet connection
But the most important problem with the flow above is simply that there are three steps, which require using three distinct programs (a text editor, an FTP client, and a browser) to make and view the simplest of changes. That’s an awful lot of work for a change like renaming an image’s CSS class from top-image to top-banner.
THE FIX: LOCAL DEVELOPMENT
Local development refers to setting up a server locally, on your personal computer. In other words, your computer becomes your web host, and you use your browser to view web files stored directly on your own computer.
For example, I’m writing this article (using WordPress’s beautiful but incomplete Front-end Editor), as a post on a WordPress site that exists only on my personal computer. That’s what the localhost:8080 in the URL bar means: the files are hosted (stored) locally, on the server that’s located on this computer, and accessed through that server’s port 8080.
Why this is cool
The first, most immediate benefit of local development is that changes to local files automatically sync to the server, because your local files are on the server. So making a change to a locally hosted site looks like this:
- Save file
- Reload browser tab
The change will show up in your browser, with no need to use an FTP client. Removing a third step and a third piece of software means that this process takes three seconds instead of twenty, which means hours of time saved across large projects.
A lot of the other advantages of this arrangement are the inverse of the problems with uploading to a remote server, but they’re still worth repeating:
- You can do web development with no internet connection.
- You’ll never lose a day of work because of a downed server—unless your computer itself is broken.
- Hosting’s free!
- You’ve got complete control over who sees and changes your project.
- You can test your project with different server configurations without having to buy a dedicated box.
GETTING STARTED WITH LOCAL DEVELOPMENT
- “How to run PHP at home: WAMP, MAMP and LAMP”: A great tutorial that will walk you through setting up a local server on a Windows, Mac, or Linux machine.
- Why You Need a Local Testing Server (and How To Do It): A verbose but good MAMP setup walkthrough with screenshots.
- Setting Up a Local Server for WordPress Development: A good WAMP setup walkthrough with screenshots.
3. Git: Smart version control for smart people
Version control, though Git, is probably the most technical of the three topics I’m covering today. It’s also very useful, so buckle up!
THE DEFAULT: VERSIONING CHAOS
Do any of the following sound familiar?
- Modifying a file, uploading it, and accidentally overwriting a partner’s changes to a different part of the file
- Multiple versions of a file, and you can’t remember which one is the “newest”
- Deleting some code that turns out to be really helpful and having to rewrite it from scratch
- Filenames like “style_old.css” and “index_final_before_redesign.php” cluttering up your filesystem
These are all examples of versioning chaos — the problem Git is designed to solve.
THE FIX: GIT
In a nutshell, Git creates a repository: a full record of all the versions of every file that are under version control, meaning that they are tracked in the repository.
Once this repository (or “repo” for l33t hackers) is set up, you can browse between versions at will. This lets you do things like:
- Compare all the differences between a file’s current code and its code at any point in the past.
- Restore any previous version of a file.
- Create a centralized repository (e.g. on GitHub) that everyone on the project can view, and that interacts with everyone’s local repositories.
- Track both the changes you and others make to a project’s codebase, including comments explaining the nature of the changes.
- Quickly and easily load the most up-to-date version of a project onto any location on your local machine.
- Create an entirely new branch of a project, which you merge back into the project’s core code once it’s ready.
How to use Git (Or. . . How to use Git?)
Now for the bad news: Git is hard to use. It’s a command-line tool by default, meaning you’ll be typing an awful lot of stuff that looks like:
git checkout -b old-state 0d1d7fc32
Git’s command-line flavor also means that some of the cool features of Git, like browsing version differences, are trapped in the Purgatory of ASCII –||– looking tables, substantially reducing usability.
Git is also just plain difficult to learn. It’s packed with obscure functions, terse error messages, and “gotchas” that break everything you try to do. More than that, Git itself is trying to solve a very hard problem: to record, organize, and reconcile every (possibly conflicting) change that anyone might make to a mass of code.
So Git is difficult to use, and very easy to get messed up in. For example, if you make changes directly to a file that’s in use by the remote master repository, Git gets very confused and you’re going to have a bad time. These types of snafus can be difficult for even a Git expert to fix, and if you’re new and get into deep water there’s a good chance you’ll give up long before you find your way out.
GITTING STARTED
To use Git, you’ll need to understand the core Git concepts:
- The basics of what a Git repository is
- Revisions, and the “Head” revision
- The Diff, Add, Commit, Push, and Pull commands
Please have these key elements in mind as you start to browse tutorial resources. Here are a few:
- “Getting Started” in the official Git documentation
- A list of Git graphical user interfaces (GUIs)
- A great introductory article, “Getting Started with Git”
In conclusion. . .
For my money, all WordPress developers should start to familiarize themselves with these or similar tools. None is a drop-dead necessity (in fact, I worked for a long time without any of them), but all three make life so much better in so many situations that they’re definitely worth learning.
So when you’ve got a spare afternoon and haven’t spent all your brain cells for the day on something else, why not crack one of these open and try learning it? You’ll be glad you did.
9 Comments