Creating Better Organized Front-End JavaScript

Creating organized and easily maintainable front-end related JavaScript files is something that took me a long time to figure out. It’s also something that I’ve noticed a lot of other people struggling with; by way of code reviews and just looking through other peoples projects, I’ve noticed just how easy it is to end up with spaghetti-like JavaScript.

The title of this post alludes to the fact that this is a method to organize your front-end JavaScript — it’s phrased this way because I understand that this not necessarily how you’d organize a Node.js app, for example.

Writing organized, well documented, and easily maintainable code is something that every developer should strive for. You should always try to make it as easy as possible for the next developer to look through your code, find what they need, and make the changes that they need.

To accomplish this, I use JavaScript objects and methods to handle any front-end related scripts. Using methods allows me to write code in a way that makes it very easy to discern what a block of code is doing and exactly when and where it’s running.

Objects & Methods

Let’s start by taking a look at an example of what I mean by using objects and methods. I’ve created a file called core.js and included the following:

var Jon = {
    setupAnalytics: function() {
        var _gaq = _gaq || [];
        _gaq.push(['_setAccount', 'UA-XXXXX-X']);

        (function() {
            var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
            ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '';
            var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);

    mobileNavigation: function() {
        // JavaScript here		

    setupPortfolio: function() {
        // JavaScript here

jQuery( function() {
    // Vars
    var $body = document.getElementsByTagName('body')[0];

    // Sitewide scripts

    // Portfolio scripts
    if ( $body.hasClass( 'portfolio' ) ) {

As you can see, organizing JavaScript this way makes it very easy to tell what code is doing and where it’s doing it. var Jon = {} is our object. setupAnalytics: function() {} is the first method within our object.

At the bottom of the document, we’ve created a jQuery wrapper function (note: jQuery isn’t required to use objects and methods, but I’m well-aware of how popular it is so this tutorial uses jQuery as an example). Inside our wrapper function, we call our JavaScript methods when and where they need to be run.

Then, all you need to do is include core.js at the bottom of your page and you’re off and running.

Managing Third Party Libraries

This method of organization also makes it easy to manage arguments that are passed to external vendor scripts and such.  For example, say you’re using a slider on your page and you need to pass some arguments to the slider script:

var Jon = {
    testimonialSlider: function() {
            auto : true,
            pager: false,
            nav: true,
            timeout: 7000,
            speed: 800,
            prevText: '« Previous',
            nextText: 'Next »'

jQuery( function() {

Project Structure

I don’t recommend concatenating vendor scripts into your core.js file. Instead, I recommend including external libraries only on the pages and contexts that they’re needed. In WordPress, you can use conditional wp_enqueue_script()‘s to accomplish this.

Personally, I use Grunt to manage concatenation and minification. So I organize all of my own scripts into an assets/js/src/*.js folder and I place vendor scripts in an assets/js/vendor/*.js folder. Then I set Grunt to concatenate and minify everything in the assets/js/src/ folder and ignore all vendor scripts.

While I understand performance concerns with adding more requests to a page, I try to organize projects in the most maintainable way possible. To me, this means managing external dependencies and libraries by themselves, rather than rolling them all into one big file and hoping that the next developer knows how to unroll them.


2014 Year in Review

For the last few weeks, Facebook has been shoving their version of what they think my year looked like in my face. Rather than share what their shitty, soulless algorithm thinks about how 2014 was for me, I wanted to put it in my own words and pictures; because that’s the only way to adequately capture it.

I’ll start off by saying that 2014 has been the best year of my life in so many ways. When I sat down to think back on all that has happened, there are three dates this year that really stick out to me. Three dates that sum up just how incredible this year has been for me.

On February 9, she said “yes.”


Brenna and I were on a weekend vacation to New York City and, despite the freezing cold, were wandering around  Midtown and the Upper East Side. What she didn’t know at the time was that I had brought along a ring and had it tucked away in my jacket pocket, waiting for just the right moment.

Around midday, we found ourselves on the Gapstow Bridge in Central Park – when I decided to pop the question. She said “yes.”

On June 23, I started at 10up.

It’s sort of a funny juxtaposition – to sandwich this between two of the biggest days of my entire life – but working at 10up has truly been a turning point for me in my career.

Prior to joining 10up, I had never worked with any other engineers; I was always the only one. Now, I’m fortunate enough to spend my days working with one of the most talented engineering teams in the world.

I’ve learned more than I thought possible in my first six months and continue to learn more and more every day.

On December 7, we were married.

Though our actual wedding isn’t until March, Brenna and I decided to also have a small, intimate Justice of the Peace ceremony with only our parents and closest friends. So, on December 7, she officially made me the luckiest guy ever.

Looking Forward

Looking back on this year, it’s hard to imagine things getting any better – I married my dream girl and landed by dream job – but there are big things on the horizon for us still.

All in all, I’m truly thankful for the way this year has gone and am incredibly optimistic about the year to come.


Clean Up Your CSS with Uncss

I’ve said a few times that the only time I’m ever truly happy with a project is right before I start writing code in it. While that’s a bit of an exaggeration, there’s certainly a hint of truth to it. By their very nature, websites change; and it’s not always easy to keep up the housekeeping as the project evolves.

Almost inevitably, I end up with a bunch of CSS that I’m not always sure is being used.

Enter Uncss, a tool built to help identify unused selectors in your CSS. It’s available as both a standalone command line tool and as a Grunt task. Uncss works by taking a set of stylesheet URLs along with a set of markup URLs, then compares your stylesheet(s) against a range of markup files.

Uncss allows you to whitelist certain selectors to avoid any dynamic elements from having their styles stripped from your stylesheet.

All in all, I’ve found Uncss to be an incredibly helpful tool. I highly recommend giving it a shot.

Pulling the Plug

Last night, I decided to pull the plug on CSSForge – a blog that I’ve been working on, off and on, for the last couple of years. The reality is that I just don’t have the time, dedication, or passion to write consistently enough to build any sort of community there.

From the start, I had always intended on it being a multi-author blog, but never pushed hard to enough to find other authors on a consistent basis. At some point, it just didn’t make sense to continue splitting what little writing that I do between multiple blogs.

The biggest factor was really that it just no longer aligned with my personal goals.

With the New Year on the horizon, I am making an effort to further cut down on the number of projects that I work on and pour my energy into things that I find more rewarding (like Word-Break Show). Consider it a head start on January goals.

I plan on continuing to write about all the nerdy webdev things I do and learn, but I’ll be doing it here instead (though I do plan on trying to contribute elsewhere, as well).


Rethinking User Experience on Mobile

I’ve been building responsive websites for a few years now, and generally consider myself to be fairly knowledgeable on the subject.

There are some established patterns that I tend to follow – dropping the sidebar below the main content, hamburger icon in the top right, etc. – and I generally feel pretty comfortable with responsive design and the challenges that it presents.

There’s one thing that all the reading about, and the implementation of, responsive design just can’t replace: actual experiences.

Earlier this week, I traded in my iPhone 4S for an iPhone 6 Plus.

I decided to go for the 6 Plus for a few reasons, chief among them being the fact that the iPhone 6 in Space Gray was on backorder for a couple of months… I didn’t want a white or gold one and I’m honestly just not that patient.

To say that my perspective on interacting with sites on a mobile device has changed would be an understatement. The iPhone 6 Plus has a gorgeous screen, everything looks so much more clear and crisp, text is so much easier to read, and being my first foray into LTE, it’s incredibly fast.

But the screen is enormous, which means the buttons seem so far apart.

In the past, I’ve always used my right hand to hold the phone and my right thumb to interact. That method of use is virtually impossible with the new iPhone 6 Plus, because the size of the phone almost dictates using two hands to interact with it (unless you have giant, NBA-sized hands).

I find myself having to move my hands to tap the top right hamburger icon, or tap the logo to return to the home screen. An interaction that is expected, and somewhat unavoidable, on tablets (which I use very, very little).

It’s a topic that Luke Wroblewski has talked about in far more depth – but even having heard his talks, it’s something that never really sank in until I experienced using a phone as large as the iPhone 6 Plus.

The experience has me rethinking the way that I approach user experience on mobile devices, challenging some of those established responsive design patterns that I mentioned earlier… like, what if hamburger icons shifted to the bottom right for a certain class of devices?

All in all, I really like the phone. It’s taking some getting used to the size, but I do love the large screen… and quite enjoy the way that it’s challenging the way that I think about responsive design.