Jacob Friedmann

JacobFriedmann.com v2.0 – Rethinking (almost) Everything [Part II]

In the last post I focused on deployment details of the new site. Today I will talk about the code itself – how it has changed and why.

Going into the v2.0 revisions I had three main goals for my code: 1.) Better readability and maintainability, 2.) Responsive Design, and 3.) SPEEEEED (really wanted to find a gif of Jeremy Clarkson from Top Gear saying this, but that turned out to be a utterly time consuming task).

Improved Readability and Maintainability

Even though I am the only one who works on my site, I often go months in between updates or looking at the code. When you’re looking at new code everyday (as I generally am), it is easy to forget the intention of certain blocks. If a problem arises, poorly structured code can make a trivial fix take hours of digging through jumbled functions. When I looked at some of my code from over two years ago, I felt my heart sink a bit and a rush of being overwhelmed by the prospect of changing anything. That is when I decided I needed to really clean it up – making incremental change more of a possibility and potentially allowing others to gain insight from looking at my code.


In Test Driven Development, we have a mantra “red, green, refactor”. This process means first you write a test that fails, then you write code to make that test pass and finally, you refactor your code to make it simpler, more elegant, more readable and more maintainable. In my first release of the site, I had reached the green phase. Now, with this release I have done some serious refactoring.

I don’t really have time to go into all of the specifics of what refactoring was done, but some of the general strategies I used were reducing redundancy, getting rid of unnecessary or unused functions, simplifying algorithms, and namespacing. On the back-end, namespacing just involved adding a custom prefix to each custom PHP function. On the front end, I used a single global JavaScript object to contain all of the functionality. This method works, so long as I don’t use another library with the same name (very unlikely).


I’ve added fairly extensive comments to all the code. Right now, they are mostly to remind me of what is going on at any point in the code, but I hope to incrementally improve them so that anyone could look at a block and understand. Documentation has admittedly been a weakness of mine (I always want to run on to the next thing), but I have been working to do some documentation at the same time as I write the code. This strategy makes it incremental and a much less daunting task.

Responsive Design

With the majority of computing now being done on non-desktop devices, I’ve decided to fully embrace responsive design. In order to do this I started with the Bootstrap framework. From there I used my own JavaScript and CSS media queries to make visiting the site a truly fluid experience.

Mobile-First with Bootstrap

Bootstrap is a really fabulous tool created originally by a Twitter employee and later open-sourced for the benefit of the world. It makes developing responsive layouts as simple as adding classes to DOM elements. It employs a strategy called mobile-first which means it first loads a layout for the smallest device and then scales up for larger devices. The thinking here is that smaller devices usually have less bandwidth and computing power than their larger desktop counterparts. Though mobile-first is really a frame of mind rather than a specific technique, one way to start doing mobile-first is with min-width CSS media queries. These insure that first the styles for mobile are loaded and then, if the screen is larger, more specific styles are calculated.

In addition to an easy to use responsive layout, Bootstrap also provides a set of common layout components that make getting a site up and running take no time at all. Some of these components include navigation bars, headers, accordions, and carousels. Finally, for the more advanced user, Bootstrap comes with a few nifty auxiliary JS libraries including Affix.js, which I’m using to fix the side navigation to this page (if your screen is greater than 991 px wide). All around a great tool. There others out there that do something similar (I’ve actually heard really great things about the new Foundation 5), but I chose Bootstrap because I needed to get familiar with it for another project.

Custom Responsiveness

One issue I ran into with my responsive design was getting my images to play nice. Bootstrap has a native way scale images for different screen sizes, but I wanted my images to hard crop to a particular size at each breakpoint. For this, I used the very cool tool imgLiquid. It essentially makes the image the background of it’s parent. This way as the parent div is being re-sized, so is the image in the layout.

Any other changes in client-side behavior were achieved in JavaScript using browser width and device type detection techniques. Most of these changes are right now in the “green” phase. Some are not true mobile-first and will incrementally be refactored towards that end.


Speed and efficiency are always a priority when programming the web, but it was particularly important for me this go around because I am now on Heroku with a very finite amount of computing power. If I can manage to do things efficiently and not waste resources, I can stay at a minimum number of “dynos” and keep paying nothing.

Asset Minifying, Bundling and Caching

When you load a web page, you are generally loading much more than the html file outputted by the server. This is typically accompanied by a whole slew of style-sheets, JavaScript files and images that make your page the exciting, eye catching experience that it is. The problem with this is that loading assets takes time. There are several ways to reduce the time that it takes while achieving the same result: reducing the size of the assets, reducing the number of assets, and when appropriate, letting the browser cache the assets so they do not have to be loaded again.

I originally was going to build a tool to do all this myself, but it turns out, I didn’t have to. I found a WordPress plugin, BWP Minify, that does all of this for me in a very clever way. First it uses a technique called Minifying to reduce the size of individual assets. This process deletes unnecessary whitespace, makes variable names shorter and generally compress a file to it’s smallest possible size. BWP Minify then takes all like assets (i.e. .css files) and combines them into one file and uses WordPress’s native script enqueue system to make sure dependencies are loaded in order. Finally, it stores this combined file in a cache folder that doesn’t need to be created again until one of the underlying assets has changed (which it does for you). This is a very cool tool and one I highly suggest you check out if you are a WordPress user.

Ajaxify Everything

In an effort to reduce full page reloads and make a more seamless (and fast) experience, I decided to make most internal links ajax calls to the server. This means that rather than reload all of the reused HTML, CSS and JavaScript at every page change, the client only needs to load a bit of HTML and maybe a few images.

In WordPress, this is actually incredibly easy. I used jQuery to disable the default functionality of a link click (a full page reload). Then I used the jQuery .load() function to load from the link’s href. The load function is very cool because you can append an element ID to the end of the url in order to only load the content of that element, which is what I wanted to do.

Wrapping Up

Revamping was a ton of fun and I learned a lot of valuable things along the way. If you have any more advice on things that I could improve, I would love to hear from you. Furthermore, if anything sounds interesting and you’d like to hear more, I obviously like talking about it way too much.

Next Post

Previous Post

Leave a Reply

© 2017 Jacob Friedmann

Theme by Anders Norén