Front-End Tooling: Do or (you won't) Die.

*Note this is not a personal attack on Ashley, but my thoughts on where I see our industry and reliance on tools going. Also it’s 4am while I’m writing this (during insomnia), so forgive me if I’m not making much sense.

TL;DR Read about everything. Learn selectively.

I just finished reading Ashley Nolan‘s fantastic ‘State of Front-End Tooling’ survey (which I took myself). I always find it interesting to see other developers’ way of going about the same issues. I do have to say I’m a bit disappointed in the results though. Obviously this is a “tooling” survey, so the results are probably going to be more skewed towards developers who actually use tooling.

My biggest issue was the belief that just because one doesn’t use any front-end tools/naming conventions/shiny-new-things, that that meant they weren’t seasoned or advanced developers. This is the paragraph that really set me to alarm:



Not using someone’s 3rd party tools/naming conventions/opinions does not make you a novice in the core language. I definitely consider myself an advanced front-end developer – I’ve been coding since I was 12 after all. But I don’t like, use or believe in most front-end tools. I don’t use anyone’s methodology either. I do *read* about these things – I even purchased A Book Apart’s Sass for Web Designers. I’ve watched Brad Frost speak on Atomic Design and his book is on my Christmas list (hint hint). I’ve taken a introductory React course or two. I’ve obviously looked into these things to see if I’m missing anything. So far, I’m not.

Clean Out That Lint

For example, I admit that I’ve been a little behind the linting trend. I don’t write a lot of pure JS, and most of the jQuery I do write (see I do use a framework or two) is pretty straightforward. I hadn’t actually heard of CSS linting until this survey. So I took a look at the CSS Lint website to see what I’ve been missing.

According to the site:

CSS Lint is a tool to help point out problems with your CSS code. It does basic syntax checking as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency. The rules are all pluggable, so you can easily write your own or omit ones you don’t want.

Sounds pretty useful, right? But then I got into CSS Lint’s rules. Most of their rules I either already do very naturally as I code, or I completely don’t agree with. Here are some examples:

  • Don’t use adjoining classes. This first rule is definitely one I don’t agree with. I adjoin all the time, especially when dealing with alt versions of the same style. This keeps code cleaner and easier to understand. And seriously, is there actually anyone still supporting IE6? Really??
  • Use correct properties for a display. Yep, I already do this naturally.
  • Don’t use too many floats. What is the theory behind not using more than 10 floats? It’s nonesense. Although I’ve ditched the majority of my floats for flexbox already, this is still something I disagree with.
  • Don’t use too many web fonts. I already refuse to use more than 2-3 fonts, so this is again, worthless.
  • Require shorthand properties. I already use shorthand properties for everything possible. (Except background-size…I refuse to incorporate it into my normal background property)
  • Don’t use IDs in selectors. I don’t use IDs very often – but I disagree with this anyways. They’re handy for certain things and there’s a reason CSS has support for them.
  • Don’t qualify headings. Heading elements should have a consistent appearance across a site. Again I call BS – try telling a designer they can only have one H2 style. HAH
  • Zero values don’t need units. I already naturally do this one, too.

And I can keep going, but you get the picture. And this isn’t personal against CSS Lint – this sort of thing seems to happen with most tools I come across.

Coupled with the fact that most of these tools require the command line…I feel like most of the time, I could’ve finished coding an entire site in the time it takes to set up these things.

And what happens when the go out of style?

LESS was popular until it wasn’t. Now it’s Sass. Tomorrow it’s PostCSS. While I admit there’s some merit in having features like variables in CSS, I’m not ready to jump on the preprocessor bandwagon. It requires a dependency on something that may not be around in a year or two. Sure, LESS sites still work…but it’s getting harder and harder to find someone who’s knowledgable in it. Also consider the fact that you know need to hire not only a front-end dev with knowledge of CSS…BUT also one with knowledge of this third party tool.

CSS is an advanced simple language. It’s simple to dive in, but hard to really learn. I don’t see the point of making it even more difficult by adding a bunch of stuff you’re going to have to remove, update or change in a year or two. All of the best properties (like variables from postprocessors) will eventually get added to CSS anyways.

Methodologies vs Tools

I feel the same about naming methodologies. Now, YMMV on this one, because I don’t work in large teams, or any teams at all. 99.9999999% of the time I’m the only front-end developer on a project. I get that these can be useful for larger teams. But IMHO most of these methodologies are just as annoying. Why name something page-hero when you can name it page-hero–top__cool (my take on BEM).


I’m probably not doing advanced enough things in JS to need this tool. I mean, do you really need a testing suite to see if the accordion works? I can see that it goes up and down in all my browser tests, and that when it fails, the heading and content still shows. I don’t need a testing tool for this.


Perhaps my biggest problem is that I just don’t like everyone’s pushyness or reliance on 3rd party stuff. I’ve been around long enough to know how fast it comes and goes. I prefer to grabs bits and bobs from everything and use what’s most appropriate. That’s my motto – use what’s most appropriate. Don’t add on 30 tools just because the next guy is.