aboutsummaryrefslogtreecommitdiff
path: root/build/posts/goodbye-css-preprocessors/index.html
blob: 4a8ef6d2e1e5ae531c787b4a04e75cd28eb27696 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<!doctype html>
<html lang="en">
<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<meta name="color-scheme" content="dark light">
	<link rel="icon" href="data:,">
	<title>Goodbye CSS Preprocessors</title>
	<link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" />
	<link href="/rss.xml" type="application/rss+xml" rel="alternate" title="RSS feed for blog posts" />
<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}blockquote{background:rgba(0,0,0,0.1);border-left:4px solid;padding-left:5px;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
</head>

<nav>
	<a href="#menu">Menu &darr;</a>
</nav>

<main>
<h1 id="goodbye-css-preprocessors">Goodbye CSS Preprocessors</h1>
<p>2017-09-07</p>
<p>I have been using preprocessors across all my side projects since they first popped onto the scene. Sass, Stylus, LESS — you name the CSS preprocessor and I&#8217;ve most likely used it because CSS preprocessors are awesome.</p>
<p>But that all changes moving forward. I&#8217;m going back to basics with CSS. Straight vanilla, man.</p>
<p><img src="/public/images/sass-cancel_rl1fsw_c_scale,w_800.webp" alt="No Sass" /></p>
<h2 id="why-and-who-cares">Why? And who cares?</h2>
<p>Let&#8217;s start by breaking down the main positives about preprocessors:</p>
<ul>
<li>Nested syntax</li>
<li>Definable variables</li>
<li>Advanced mathematical functions</li>
<li>Reusable mixins</li>
</ul>
<p>All of these features are great and I completely understand the draw (I was also sucked into the hype) - but now let&#8217;s see the negatives.</p>
<h2 id="1.-debugging-is-a-chore">1. Debugging is a chore</h2>
<p>So you found some weird padding clobbering an element&#8217;s default styles on line 255 of your main complied CSS file? Excellent! Now you just need to figure out which file that property comes from.</p>
<p>This might sound trivial or that you can fix this with rendered comments but if you ever work on a project with hundreds of Sass&#47;Stylus&#47;LESS files all importing and compiling into each other - it can get out of hand.</p>
<p>Solution: Using plain CSS makes using browser dev tools a breeze. See a bug on line 255? No problem, let me fix line 255.</p>
<h2 id="2.-dependencies-for-development">2. Dependencies for development</h2>
<p>Building a project with a preprocessor brings with it unnecessary baggage; dependencies. You&#8217;ll need to be running some sort of task runner (see grunt or gulp) that will compile and minify your CSS. I see this as extra overhead both during the initial setup of the project for new team members and the testing environment.</p>
<p>By using plain CSS, you avoid including an extra package in your package.json file (if applicable) or having to rely on third party compilers such as codekit (although I do recommend this app).</p>
<h2 id="3.-variables-mixins-become-unwieldily">3. Variables &#38; mixins become unwieldily</h2>
<p>Both variables and mixins are great in small doses, but if your project has any real size to it these helpers become a hinderance. By using comma-delimited CSS selectors you can achieve the same outcome without the horror of needing a specific preprocessor file to handle just variables and mixins.</p>
<p>Basic example:</p>
<pre><code>selector, selectTwo, .css-class {
    &#47;* shared styling *&#47;
}
</code></pre>
<h2 id="4.-welcome-to-nesting-hell">4. Welcome to nesting hell</h2>
<p>Honestly, I&#8217;ve never been a fan of nesting. From a file structure perspective it is indeed very &#8220;clean&#8221;, but you sacrifice that cleanliness in the final compiled production code. You&#8217;re making your development environment easier to glance at and work through at the cost of your production-ready, customer facing code.</p>
<p>You also run into another big no-no in my eyes: extreme selector specificity. The DOM target search starts to get out of control once you start having classes and selectors building up towards 10 or more steps.</p>
<p>Bad:</p>
<pre><code>body #home .container .modal nav .inner-nav &#62; ul &#62; li &#62; a {
    color: red;
}
</code></pre>
<p>Good:</p>
<pre><code>.inner-nav a {
    color: red;
}
</code></pre>
<p>Don&#8217;t forget the amount of work needed to override styling with such deep selector specificity. That&#8217;s where you end up diving into the world of !important tags.</p>
<h2 id="final-thoughts">Final thoughts</h2>
<p>It should go without saying that this is just my personal preference, there is no law behind this. If you use and absolutely love preprocessors - more power to you. All I suggest is using plain old vanilla CSS for your next project and see how it works out.</p>
<p>And do you know what I&#8217;ve learned to appreciate after switching back to vanilla? CSS is more beautiful when developed in it&#8217;s rawest form.</p>
<footer role="contentinfo">
    <h2>Menu Navigation</h2>
    <ul id="menu">
        <li><a href="/">Home</a></li>
        <li><a href="/projects">Projects</a></li>
        <li><a href="/uses">Uses</a></li>
        <li><a href="/wiki">Wiki</a></li>
        <li><a href="/resume">Resume</a></li>
        <li><a href="/colophon">Colophon</a></li>
        <li><a href="/now">Now</a></li>
        <li><a href="/donate">Donate</a></li>
        <li><a href="/atom.xml">RSS</a></li>
        <li><a href="#top">&uarr; Top of the page</a></li>
    </ul>
    <small>
        Built with <a href="https://git.sr.ht/~bt/barf">barf</a>. <br>
        Maintained with ♥ for the web. <br>
        Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> &amp; <a href="https://nextdns.io/?from=74d3p3h8">NextDNS</a>. <br>
        The content for this site is <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>.<br> The <a href="https://git.sr.ht/~bt/bt.ht">code for this site</a> is <a href="https://git.sr.ht/~bt/bt.ht/tree/master/item/LICENSE">MIT</a>.
    </small>
</footer>