The first thing people use in a framework (at least it feels that way) is the grid system. In Bootstrap you have classes like .col-md-1 to indicate one grid unit, in Foundation .large-1 accomplishes the same thing.

Both Bootstrap and Foundation are based on a 12 column grid. So those classes above are asking for 1/12 of the grid. Bootstrap implies we’re working with desktop styles. Foundation makes it a bit more obvious by adding “large” to the class.

If you want to assign a column to be 1/2 of the width of the screen on mobile, you would write:

Bootstrap: .col-xs-6 (xs = extra small)

Foundation: .small-6

When you want to make things responsive, you can mix and match those classes to get it right.

Bootstrap

<div class=“col-xs-6 col-md-3”></div>

Foundation

<div class=“small-6 large-3”></div>

Freedom

Now there’s nothing wrong with those grid systems. But for me, I don’t use Bootstrap or Foundation because of all the overwriting of styles that I have to do to make something look unique. So, I don’t include Bootstrap or Foundation just for their grid system. For me, since I’m not bound to a framework, I get to choose the grid system that makes the most sense to me. Instead, I use Unsemantic on most of my projects.

Nathan Smith, who wrote Unsemantic, used percentages to build the grid system. So, if I want a div that sits at 50% width on mobile and 10% on desktop, that looks like this:

<div class=“mobile-grid-50 grid-10”></div>

By just using .grid-10, I get the desktop styles. Adding mobile- or tablet- to the class applies that style if the reader is on a mobile or tablet device.

Application

Now, for a long time, I wrote my divs exactly as seen above so that other people could figure out what I was doing:

<div class=“sidebar mobile-grid-100 grid-25”></div>

Usually there’s another class in there anyway, in this case .sidebar. So instead of adding a series of classes in my HTML, I’m now making use of Unsemantic inside my SASS files as often as I can. So I write something like:

.sidebar {
    @extend .grid-25;
    @extend .mobile-grid-100;
    /* More styles go here */
}

By adding them in the SASS file they’re included in the CSS files when that’s all combined. As a result, my HTML is more minimal. My SASS files stay cleaner, too. By using @extend, I can do widths, margins, padding, and responsive styles all in one single line.

Impacts on Design

The biggest departure isn’t the grid-10 vs col-1 vs large-1, it’s in the design phase. If you design for Bootstrap or Foundation (or just prefer 12 columns), not having 12 columns as a basis can be a little jarring. But for me, if I look around at other designs, most of the basics exist in all three systems. 1/3 is still 1/3, regardless of whether it’s 4 columns or 25%, for example. But Unsemantic doesn’t break down into twelve parts you get ten instead.

If that bugs you for some reason, I’d recommend Gridset. You can get as granular or particular with your grids as you want. If a 5 column system appeals to you, hey, you can make that. What about a 7 of varying sizes? Yep.

I used Gridset for a long time, and I love it. But most of the time I don’t need that level of complexity with my work. Most often it’s a 66% content block and a 33% sidebar or something like that.

So whichever way you need to work, you have options. But you don’t have to feel as if the only way to build something is by using a full framework.

In the next article, I’ll cover Typography.

I thought, as the question was being asked, that my honest answer was going to cost me the role.

My exact response is really blurry at this point, but the gist of it is that…

1. I wouldn’t consider myself the best in anything, because there are a lot of smart people who specialize in things.
2. I focus my time on HTML and CSS, because regardless of what back-end languages, or JavaScript libraries are in play, they all tend to need HTML and CSS at the core of it.

Apparently it was the right answer for this team, however.

At the time I had worked in web apps, where the entire thing was written in Rails/Java/.NET and I just had to make the front-end work. And I had also worked on apps that were front-end heavy, written in AngularJS or Backbone. Even the iOS development work that I’ve done fell into that second category.

If you can write HTML and CSS well, it takes away a whole lot of cruft from the interface. You don’t have random unnecessary tags floating around. Things aren’t in tables, unless you’re working with tabular data. And you can often speed up the UI by not leaning on JavaScript in the first place.

Frameworks

But there was a bigger context to that question, which revolved around Bootstrap and AngularJS.

At the time, I had been working on apps that used (and occasionally abused) Bootstrap or Foundation. One of those apps also happened to use AngularJS. Another still used Bootstrap, AngularJs, and a few random bits of CoffeeScript because someone wanted to upgrade their resume.

I could certainly write Bootstrap specific HTML, I didn’t consider it hard or a big, scary unknown. It’s just not for me. I’ve built my career on being a minimalist HTML and CSS writer, and that has never failed me. Not once.

But having that skill gives me an opinion about Bootstrap and the HTML and CSS that it expects.

Now, I’m not at all hating on Bootstrap. Use it or don’t, I don’t really care. But for me, I never use 95% of Bootstrap, or any other framework. There’s a ton of stuff that nobody uses. But yet, if I choose it, it sits there in my project. Sometimes, Bootstrap updates, and things break. I have to rewrite code, update classes, etc. But minimalist stuff just doesn’t move. It stays in place.

And of course, the more weight my scripts and CSS files have in them, the more of a pain it is to get that stuff loaded into a browser or mobile device. (One of my recent Angular projects had about 500KB of scripts alone.)

I see so many job posts asking for something particular, like Foundation or Bootstrap that it’s easy to see why young front-end developers focus on it. And with the variety of things that a framework like that can do, it’s easy to see why they’re often “the obvious choice.”

But I think there’s a better way forward. In the next few articles, I’ll be writing about my own processes and how I go about building sites. I’ll be starting with the bits of CSS and HTML that I use in almost everything I build.

Part 2: Grid Systems

I had spent two or three weeks on a car that, while it could drive, it was too eager to roll and flip. (It was as if the tires were made of springs.) Though I have a lot of experience programming on the web, I needed to find someone to help get the nuances figured out in Unity.

So I sent word to a popular job board that I was in search of a Unity developer. It was a short note, but I was clear up front that I wanted to see their work, and I needed to know their rates.

In the dozens of responses, only one person sent both rates and examples of their work in the first email. Most people would send over their resume and ignore that second part.

At first, I just assumed people had overlooked that detail. So, when someone who seemed qualified sent me their resume, I politely asked for their rates.

For whatever reason, that turned out to be the fastest way to remove applicants from the pool. When I asked for their rates, people with whom I had been in conversation about the role would walk away without another word. It was as if I had just asked them to sell their soul. (I wasn’t, I promise.)

But the uneasiness wasn’t always blatant. One person kept me in conversation for well over a day, getting various details about the project. I appreciated his interest in the details, and getting to the bottom of how our relationship would work. But in the end, he misjudged how large our company is and bid the project at over double our company rate. When I looked back at the conversation transcripts, it occurred to me that he too had been stalling to figure out how to answer the question.

Money is Odd

In modern society we need it to survive, and some people even allow it to own them. It’s this awkward transactional thing that lets us feed our families and keep the lights on.

I understand how unnerving it is to talk about rates, too. As a contractor, you know you have to hit the number right on the head to even stay in the running. Bid high and you’re off the project, bid low and you’ll be perceived as inexperienced and unable to take the project.

Believe me, I would much rather not have to deal with the financial side of business. I would do this stuff as a hobby if money weren’t a thing. But part of being a professional is getting past the aversion to talking about what things cost.

You aren’t your hourly rate or your yearly salary. Your skills and time aren’t so easy to match with a value. If that were the case, nobody could ever afford any of us. Somewhere deep down we all know this.

But as someone who has needed to set an hourly rate for a long time now, I can tell you that it does get easier. And perhaps you don’t want to work under an hourly scheme. That’s fine too. But be able to explain your pricing structure to someone who is looking to hire you.

Being unable to answer the question shows a lot more professional immaturity than giving the wrong number. If you bid high (within reason) I can ask you to take a lower number if your skills match. If you’re young and don’t really know what to charge, put a number out there. Make it a realistic number of course. I can’t speak for every “boss”, but I’ll often raise a person’s salary if they’re not asking for enough. In my opinion, a fair wage is on both parties.

So when someone asks you for a number, just give it to them. And don’t apologize for it.

As the poor creature spun around in circles on its way to a watery grave, I replayed the events over and over in my head. I still cannot be certain my report is completely accurate, I was both sleep-deprived and under intense stress.

Like a political lobbyist’s intern, my alarm clock faced great difficulty in calling me to action. And so it was that morning. I was nowhere near deep sleep, though I was closer to it than I was to being awake. In the past forty minutes I had tapped the snooze button on my alarm clock no less than 5 times.

I lay there rolling the idea of being awake around in the back of my mind, but it was a lofty goal that I wasn’t sure I would reach.

And then I felt it, a subtle brushing across the back of my neck. It came in quick flutters against the base of my hairline, a strange alien motion that I couldn’t compare in my sleepy state.

My subconscious could. It nudged me awake with the urgency of a small house fire.

When my eyes were open, I brushed it all off as any other dream. But as soon as my eyes closed and I let myself relax, I felt it again.

My subconscious forced me to action and I reached up in self-defense, slinging whatever it was as far away as I could manage. I sat up in bed, scanning the room for whatever it was, but I saw no sign of it anywhere.

I cannot explain how the next part happened. Even something as cliche as a dream within a dream seems as likely a scenario as any. I don’t recall putting my head on the pillow again, but the next thing I remember is a sound echoing through the pillow.

It was the sound of fluttering wings against the light material of the pillowcase.

I bolted upright, completely alert. At the top of the pillow a giant cockroach looked up at me with an evil glint in its eye. It did not speak, not with a voice you could hear. Instead, it twitched its antennae back and forth until I understood its telepathic message.

“I claim this house in the name of our queen. You are to report to the palace at once for registration.”

I assume by “palace” he meant the cabinet beneath our sink.

Out of respect for the diplomatic process, or maybe because it rested on MY pillow and I could not kill it outright, I captured it in a glass. (It is the same courtesy I show spiders after all.)

In hindsight, the glass was neither covered nor deep, and it was a terrible choice of vessels in which to transport a prisoner. The poor decision was obvious when I flipped the glass upside down to shake the roach into the toilet. Instead of falling to its demise, it leapt with gazelle-like agility to safety.

But that safety was short-lived. Inside the nearby closet, my old trusty boot was ready for action. The now aging leather, though cracked, met the ground with a loud thud.

I take no pleasure in the death of a cockroach. But by its own telepathic admission of guilt, it was in my apartment on a mission of conquest. And our apartment is not large by any stretch of the imagination. We would have needed another bedroom for a cockroach of that size.

A shower was in order, perhaps to wash the blood of war from my hands. After that my daughter woke up, meeting me in time for breakfast at the dining room table.

I had already put the bacon in the oven, and the eggs were on the stove when I heard her shriek. She was across the room, but the open-plan of the kitchen and living area gave her a clear line of sight to where I stood.

“Look!” She yelled, pointing in my direction.
“What?” I asked, not entirely sure her cries were warranted.
“A bug!”

On the ledge just above the stove crept a lone scout. It wore the marks of its clan across its face like a tribal warrior. With a twitch of its body, and a flick of its antennae, it stopped forward motion and reached out with its telepathic fingers.

“I know what you did,” a slippery voice in the back of my mind scolded.

And I believed it.

But it could not escape fate. There was a fancy candle with enough heft to get the job done, and leaving a witness is a bad idea.

There would be one more death before the sun had risen above the top of the moss-covered trees. But knowing that one cockroach was agile enough to escape is what keeps me on edge today. The war has begun indeed.

For the development phase, I teamed up with the newest member of Northward Compass, Kyler. Together we built out the HTML, and CSS. The site runs on the WordPress CMS.

Each page of the main site is different, and it builds a collection on the front page using the Textpattern CMS.

We built this on the Textpattern CMS, and incorporated some of the photos taken for her album.

One month ago, I started on the paleo diet. My goal was to make it a year, being as consistent as I could. Well, the first month is down and so far (aside from a few things here and there) all is well.

I haven’t downed a cake, or eaten bread. Those are my two biggest cravings when I actually have them. (Like now, because I’m writing about it.)

Sometimes it’s still a pain to eat at restaurants because there just isn’t a true paleo option. So I end up eating a salad, which of course isn’t always filling (or good). But that’s not to complain, just to state the reality of it. It’s impossible to eat outside of the house and be truly on paleo. Even the steak I had the other day was covered in preservatives. But it was my wife’s favorite restaurant, and the only thing on the menu pretending to be paleo-esque.

Weight Loss

In the month of July, I lost 18.5 lb. But that’s without trying. I never really felt hungry except for the initial phase of breaking out of sugar and carb addiction. (That first week back on Paleo, I just want to hijack every bakery truck I see.) And while lately I’ve been eating more salads, I’m not feeling like I’m starving. It’s just easier now to eat reasonable meals since the actual calories add up just fine.

Other Symptoms

A couple weeks ago I was getting heartburn pretty consistently. I dropped the amount of coconut oil I was using and it went away. I think the culprit was how I was cooking my eggs in the morning, though it never felt greasy.

Before getting back to Paleo, I was getting an occasional chest pain. But that hasn’t happened once since I started Paleo. I was diagnosed with reflux disease a few years back, so I knew ahead of time that it isn’t tied to my heart, just diet/caffeine.

A friend of ours reported that when she cut gluten, her sinuses cleared up, and I was hoping that by dropping dairy and gluten the same might happen for me. It’s possible that my sinus issues have gone down a little bit, in fact, now that I’m actively writing it I’d say they probably have. But it’s not completely “fixed”, which is something I was hoping would just happen.

Overall

Though the progress is good, I’m not stopping. I assume that in this next month I’ll notice a plateau in my weight loss, but it’s too early to say. My goal is to continue eating right within my calorie allotment without adding any exercise. And, this month I’ve not stood up to work a single day. So anything I’ve lost is because of the diet. Seriously, I’m sitting down more than is actually healthy. I do need to fix that.

But so far, so good. If you’re curious about how the progress worked out for any given day, I’m keeping a log of the progress in a paleo journal.

The first thing I learned about web development was that there was this thing called “Web Standards”, and it was awesome. We as an industry are better for it because it’s inclusive and altruistic. People with screen readers, for example, benefit from it because we knew better than to just use Flash on everything. You’re probably not writing your HTML into tables these days, so thank the web standards movement for that too.

But web standards also ventures into things like removing onClick=“Insert your JavaScript Here” from your HTML, and instead advocates for placing that JavaScript in your actual JavaScript file. And that’s smart, because when you’re working on a web app, or a site with a lot of pages, you don’t want to go through and pull out references to things you use over and over again.

In fact, that has been one of my primary frustrations with AngularJS. It’s so much of ng-click=”“ that it’s basically a collection of “bad practices”.

The Problem With that

We’ve been working hard on an iOS app over at Artletic. We opted to use the Ionic Framework, but not all of the Angular JS stuff because, well, at the time it didn’t seem to be necessary when all we wanted was some HTML and some JS. I set the thing up on day one and it just flew. Seriously, it was quick.

Fast forward to last week and the app was just dragging on my actual iPhone 4. Now, that’s on a 4. It was semi-usable on a 5, but not everyone has a 5. In fact, I could hardly test the latest features because it was so slow on my phone.

So I remembered something that happened to me a few years ago when I worked at (what was then) Fellowship Technologies. I created this nice and orderly list wherein people could interact with their data. However, we never tested it with thousands of entries. Shortly after, Nathan Smith and I (mostly Nathan) refactored my code to work for larger sets of data because it had a serious performance drain under those conditions.

The Wisdom in Being “Wrong”

The way he did it, was to rework and then reference the JavaScript function with an onClick. Why did it work? By registering click events for every last one of those thousand items, there was just so much extra memory weight that it dragged down the app. Putting things in the HTML itself meant that the browser didn’t have to roll through every entry and create those events, then watch each and every one of them. It meant that the browser didn’t have to care until you interacted with that data. Then, it would see the onClick event and take action… But only when you clicked it.

In my Ionic project it was the same thing, but on a much smaller and finicky scale. My browser was completely fine with the JavaScript, the simulator was fine with the JavaScript, but the actual device was not. The iPhone is a much lighter device than my Macbook (obviously), there should be no expectation of comparability.

I had been using the module pattern, and each click event was already referencing functions.

Before, it looked like this:

$('body').on('click', '#something', function ( ){
	interaction.load_something();
});

But for performance’s sake, I changed it to be this:

<a href="#whatever" id="something" onClick="interaction.load_something();">Whatever</a>

When there are large sets of data, that markup is neatly placed in a Handlebars template that gets added and subtracted from the DOM as necessary. It’s just as performant if there are one or a hundred things in the list, and because it’s included in a partial, I’m not having to maintain that code in 100 pages across an app. And I think that’s why AngularJS uses hg-click as well.

The speed increase was immediately apparent. I removed the click function in my JS file for one of the biggest offenders, and the app was suddenly very usable. It wasn’t as usable as I wanted it to be, however, but when we removed a good number of the click events it sped up quite a bit.

So while it wasn’t exactly a tactic that I’ll be applauded for in the web standards community, it saved our app and, thanks to Handlebars, still kept me from having to weed through too much JavaScript in my HTML.

In Reality

This really isn’t an anti-web standards post. Honestly, the old wisdom is so good that most of my sites will still use the same module pattern and click events routine. But when I’m building something mobile/hybrid, inline click events are a small price to pay for what could be a large number of happier users on aging, lightweight devices.

What I Was Doing

Because I had mostly been working by myself on things, I was running CodeKit or even SASS/Compass from the command line. It works, obviously, but when your teammates want to run something else, like Prepros, for example, not all apps build things the same way.

Sometimes it was a minor difference. The first thing we noticed, for example, was that one of our apps was adding in line-numbers while the other one was not. It’s fine, until you work in a shared Git repo and suddenly those line numbers are all changes that need to be merged.

Or in some cases, because I was using CodeKit to also minify my JavaScript and lint it for errors, we would run into differences in which files were being included at what points. So while it worked fine for me, my coworkers were throwing errors because one library was being included before jQuery, or it just wasn’t being pulled in at all.

It was a mess, an actual mess.

Enter GruntJS

I had heard things about Grunt, but I wasn’t buying into the hype. Until I got really frustrated one night and decided that it was either give it a shot or hate working with pre-processors and minify everything by hand.

Within an hour, I was up and running on Grunt. I now use it for every last project because, well, I have too much to do to fight inconsistencies with teammates. (Totally not their fault.)

Configuring Grunt

I won’t get into the install steps, because the Grunt site does that rather well: Getting Started.

But what might be more useful is to show how my Grunt file is helping me.

module.exports = function(grunt) {
	'use strict';
	grunt.initConfig({
		pkg: grunt.file.readJSON('package.json'),
		concat: {
			options: {
				separator: ';'
			},
			dist: {
				src: ['/_js/jquery.js', '/_js/handlebars.js', '/_js/raphael.js', '/v10/_js/g.raphael.js', '/_js/g.line.js', '/_js/interaction.js'],
				dest: /_js/interaction.min.js'
			}
		},
		jslint: { // configure the task
			// lint your project's client code
			client: {
				src: [
				'/_js/interaction.js'
				],
				directives: {
					browser: true,
					predef: [
					'jQuery'
					]
				},
				options: {
					junit: 'out/client-junit.xml'
				}
			}
		},
		sass: {
			dist: {
				files: {
					'/_css/screen.css': '/_css/screen.scss'
				}
			}
		},
		uglify: {
			options: {
				banner: '/*! <%= pkg.name %> <%= grunt.template.today("dd-mm-yyyy") %> */\n'
			},
			dist: {
				files: {
					'/_js/interaction.min.js': ['/_js/interaction.min.js']
				}
			}
		},
		watch: {
			files: ['/_js/interaction.js', '/_css/*.scss'],
			tasks: ['concat', 'uglify', 'sass']
		}
	});
	grunt.loadNpmTasks('grunt-contrib-concat');
	grunt.loadNpmTasks('grunt-contrib-uglify');
	grunt.loadNpmTasks('grunt-contrib-watch');
	grunt.loadNpmTasks('grunt-contrib-sass');
	grunt.loadNpmTasks('grunt-jslint');
	grunt.registerTask('default', ['concat', 'uglify', 'sass']);
	grunt.registerTask('tests', ['jslint']);
};

Grunt and Concatenation

To break that down, there’s a bit of configuration before we get to this important bit here:

concat: {
	options: {
		separator: ';'
	},
	dist: {
		src: [‘/_js/jquery.js', '/_js/handlebars.js', '/_js/raphael.js', ‘/_js/g.raphael.js', '/_js/g.line.js', '/_js/interaction.js'],
		dest: '/_js/interaction.min.js'
		}
	},

As you might have guessed, that’s the concatenation function. It grabs everything listed in the “src” array and uses it to create interaction.min.js. If you were to run just that, it would be as if you manually copied and pasted all those files into one, large JavaScript file.

Next up, we have the JSLint plugin which opens up just my custom JavaScript file, and looks for errors or syntax issues. A point of consideration here is that I’m working only with the “client” code block. If you’re a NodeJS developer, (you probably already use Grunt), but you can also separate your server code to be linted.

Grunt and SASS

The SASS section caught me a bit off guard at first, because it reads backwards to me, but it looks like this:

sass: {
	dist: {
		files: {
			'/_css/screen.css': '/_css/screen.scss'
		}
	}
},

All it’s doing is taking that second file (/_css/screen.scss’) and using compiling it to the first (/_css/screen.css). Now for me, I have a bunch of other SCSS and CSS files that I include in screen.scss, but they don’t need to be pre-compiled. So this is the extent of it.

Grunt and JavaScript Minification

The next function is Uglify, which is this block:

uglify: {
	options: {
		banner: '/*! <%= pkg.name %> <%= grunt.template.today("dd-mm-yyyy") %> */\n'
	},
	dist: {
		files: {
			'/_js/interaction.min.js': ['/_js/interaction.min.js']
		}
	}
},

The options section just creates a stamp at the top of your file, in this case I have the package name and the timestamp for today. But the “dist” section is the important part. In the concat function, we’re building interaction.js into interaction.min.js, which until this function runs, isn’t actually minified. If I were to point this function at interaction.js, it would minify my source, and that would be awful to maintain. So all we’re doing is taking that temporary file from above and minifying it instead.

Watching for Changes

And lastly, we have the watch section:

watch: {
	files: ['/_js/interaction.js', '/_css/*.scss'],
	tasks: [‘concat', 'uglify', 'sass']
}

All this does, is keep an eye on anything listed in the “files” array for changes. If any of them change, it runs the other functions in order. (Concat, uglify, SASS). And this is key here. If you were to switch concat and uglify, you’d always see unminified code. And, if you’re only working on the CSS side of your project at any given time, you can move “sass” to the front of the list and have your output faster.

After the functions are all defined, we get to some Grunt commands that load the actual modules to do the work, but the last bit of importance for us is this:

grunt.registerTask('default', ['concat', 'uglify', 'sass']);
	grunt.registerTask('tests', ['jslint']);

The first line instructs what should happen if I were to run Grunt without any other options. It would roll through concat, uglify, and sass, just like in the watch function. The second line, only runs the JSLint function. Personally, I don’t like to have JSLint yelling at me every time I need to compile the scripts, or worse, CSS. Sublime text can already do basic linting as I write.

Running Grunt

Now, once this file is in place, I can open terminal and find the root of my project. Then, it’s just as easy as typing “grunt.” Doing that would load the default function. But, I don’t do that very often since I’d have to do it over and over again. Instead, I usually run:

grunt watch

That invokes the watch function and keeps an eye on the JS and SCSS files I work with.

And while there’s a lot more you can do with Grunt, I personally don’t need anything more than this. I’m sure as I get deeper into Angular JS and Node JS that will change, but for now, I’m content with just having a way to get my whole team onto the same page without conflict over the files we work with most often.