Skip to content


I’m a bit predisposed to minimalism, but recently simplicity (in various forms) seems to keep bubbling up in various blogs and things. When you simplify things, it’s often easier to see what’s going or what went wrong.

(Writing this post turned out to be a good reminder to myself at how easy it is to make things long or complicated. I kept going off on tangents or wandering of in a related, but not entirely relevant, direction.)

Three particular flavours of things that I’m been thinking about / seeing:

  • debugging JavaScript;
  • adding custom stuff to Bootstrap;
  • having lots of WordPress Plugins.

Debugging JavaScript

The students in their first term at codeX are writing their first bits of JavaScript, so they’re finding out lots about how it works. And lots about how it doesn’t work!

When a new bit of code isn’t working as expected, one way we try and find out what’s gone funky is commenting out big chunks of code. Looking at a small amount of code and trying to find an error is much easier than looking at a big bit of code with lots of things going on (Later on we talk about modules and splitting things up into nice small chunks).

Adding custom stuff to Bootstrap

I like using Bootstrap as a prototyping tool because it’s fast to make stuff with it. It’s also a good learning tool. If you’re new to CSS, you can get something looking pretty good pretty fast, then dig under the hood a bit to see how it works. At the moment we’re using it at codeX like that.

Complexity comes in here when you want to customise Bootstrap, usually by adding a small CSS file of your own with extra styles. Bootstrap’s styles are quite far-reaching and “heavy” (“high specificity” if you want to be fancy), so they can be difficult to override (and figure out what to override). It can lend itself to using naughty CSS like !important, and you end up with your own stylesheet being complicated and hard to understand.

I’m starting to steer people towards using lighter solutions (smaller frameworks), or writing their own CSS from scratch. I’m also talking about the dangers of using frameworks or libraries by default, without really considering the consequences to you, your team, or your users. Adding things to get the end result you want can be easier than over-riding things to get the end result you want.

Having lots of WordPress Plugins

With the popularity of WordPress, and the (relative) ease of writing (WordPress-flavoured) PHP, it’s not surprising that there are lots and lots of plugins out there. Many of these offer convenience for the author (good), at the cost of weight and speed for the reader (bad), and complexity for the developer (bad). It can be a little too easy to keep adding plugins until the Dashboard looks like Microsoft Office products did a few years ago.

And on the reader side of the site, things can be kind of similar. When developer needs to make a change to the styles, it can become a bit of a sleuthing mission. It might come from the content or the Theme or a Plugin, and they can interact with each other in unexpected ways.

One way to do deal with this is to do less. Take a long, hard, look at the things you have and ask which ones really need to be there. Focus on a handful of the most important things, and get rid of the rest. If you don’t really need that social sharing toolbar, you can remove that Plugin. If the author is willing to learn a little HTML, you can remove that other Plugin that does fancy links and buttons and things.