How It Started
In 2011, I sat at the Gingerman in Austin (RIP) during SXSW chatting with other designers and developers about @mdo and @fat’s CSS Design System and Framework they designed at Twitter, then called Twitter Bootstrap. The potential was more than just about quick spin-ups of sites or applications, it was about better default styles than what the browsers came with (or your choice of CMS) and bringing the jQuery library of default functions (sliders, collapse, responsive embed, etc) to the table. This was just the beginning of saving time as well as expanding the mind of developers, who were building everything from scratch for each project. We joked that it would cut down on our copy and paste from previous projects, too.
Fast forward to 2019. Tailwind CSS is released and Bootstrap is away from Twitter and working through the beta of its fourth major version. While Foundation has also been around for a while, too, Tailwind quickly gained traction, especially amongst JS application development (React, Vue.js, to name a few) and for many developers looking for a new framework to sink their teeth into. Between these three frameworks, you find the names of each coming up in job postings requiring familiarity and/or expertise in order for new developers to align with the new teams that they will join. CSS Frameworks are a legitimate tool with which employers desired new employees to have skills.
How It’s Going
For many front-end developers, choosing a framework and sticking to it isn’t hard. For the most part, they are all quite similar but have enough differences so you won’t make a bad decision based on the frameworks themselves. We’re in a great spot when what they provide isn’t the problem. What is the problem with these frameworks is their bulk size, which grows worse if the jQuery library is required to be loaded on a web page to correct certain browser issues and run framework functions from the framework’s main Javascript file.
For some technical comparison, the default Tailwind configuration comes with 36.4KB minified and g-zipped. Bootstrap comes in at 22.1KB , making Tailwind is 14.3KB heavier. If jQuery is needed (Bootstrap version 5 drops the need for jQuery), add a minimum of 28.87KB to the mix. Respectively, that is 65.27KB and 50.97KB loaded on every webpage, before you load the default stylesheet and any other stylesheets, scripts, or other dependencies that a webpage needs to completely load. When the site speed question is brought up by non-developer SEO experts, guess which libraries or frameworks are going to be looked at before image size/compression is brought up?
How I Could Change
Let’s be honest, a lot of us don’t think about these things and just build and upload and move on. We need some sort of boilerplate that avoids huge libraries we barely use. With user experience or SEO, site speed and load time are huge considerations when building a site. Often, you can’t help how many elements are loaded on a page, due to the scope and needs of the project, so taking frameworks and libraries into account, there is a possibility to save a conversation and or the need for iteration that could be costly time-wise.
This led me to see if I could fix this problem on my own, for myself at least. I didn’t want to go through and edit one of the big frameworks, but I did want to try my hand at making my own. This led to building Jimi.
Building Jimi
I started with this question; what do I need at a minimum on every page?
For starters, I need a CSS reset, some sort of basic styles for text, a grid and modifiers (because I’m using Flexbox), and standard responsive elements with images, the grid, and its modifiers. Okay, so that gets me down the road and on to building something.
Now, a webpage or app isn’t just those things. That’s the empty plate, right? I need some more help. Horizontal lines, lists, buttons, and form fields.
From these two files, I can load my styles into the main CSS file and get the colors needed, so we can start building the custom styles for the rest of the site.
Why It’s So Minimal
The previously mentioned frameworks are built to think of everything, but I don’t need to think of everything anymore. I need just a few things and then I’ll be the one building the rest, which makes more sense that it is more like a boilerplate under the guise of a framework. Over the past few years, I found myself overriding so many styles from the Bootstrap default file, because the design called for it. Why have the duplication, when you build styles once! This helps with troubleshooting and when you come across a bug, you fix it once and you avoid the scary (and bad practice) of !important, which is used way too often that we like to admit.
There also is no Javascript. Before these frameworks, many of us cobbled together elements from books or used Adobe Flash to build elements like sliders or add animations. Now with these built into frameworks like Bootstrap, they are used everywhere. But largely, I don’t need them or I need more flexible versions as Slick Slider offers. This drew me to, at this time, not add any Javascript elements and let the project dictate if I needed it or not.
The Future
Currently, I have dropped Jimi on my personal site here. I plan on continuing to use it here through the next iteration and beyond. I’ll be building it for me and what I do, although it’s available to download on Github for anyone to use. Maybe someday soon, I’ll use it with a client and learn even more!