This is the first article in a three-part series discussing the inner workings of a front-end web framework, why one might want to create such a framework, the challenges that will almost certainly arise and other relevant things. Bear in mind that most of what is to be discussed below is based on my personal experience, workflow and design philosophy as seen on my CSS framework, mini.css, so take my advice with a pinch of salt.

Frameworks – We all use them, we all sort of like them but we also feel like there are aspects of them that we’d like to be different. This last part is what had me worried for a while, as I saw more and more posts on programming and web design subreddits about how Bootstrap, Pure or even [insert your favorite worst front-end framework here] are not good enough, bloated etc. So I made the not-so-bold-but-kinda-bold-still decision to code my own front-end framework.

“Why?” many of you will ask. Well, I saw it as a learning opportunity which is probably the worst case scenario. The best case scenario was a competent framework that I could use for a while and improve it as much as I wanted in the direction I wanted without needing to ask around all the time because I would know what was happening behind the scenes. For the most part, I got the best case scenario and created mini.css. I’m gonna give you the elevetor pitch first, so you know what it is about, and then I’m gonna walk you through some of the first steps and in the next couple of articles we’re gonna discuss the challenges I faced and other relevant details, such as improvements and such. So, what is mini.css?

mini.css is a tiny framework (about 5KB gzipped), that works well on mobile devices, is responsive, contains a reasonable amount of modules and components and is style-agnostic. It’s built using Sass (SCSS) without any Javascript and tries to use best practices as much as possible. It comes in flavors, so you can choose what you need and what you want components to look like and you can even build your own flavor using a simple file with variables and mixin calls.

I am not gonna debate if we needed another front-end framework or not, but I’m gonna say I thought I did and that was enough. So I started on it with just a few key ideas that I thought I should have in mind to sort of differentiate myself from the current frameworks:

Code brevity, avoiding bloat and unnecessary components, styles and overall features Mobile-friendliness and responsiveness Customization to one’s liking CSS purity

To clarify about (4), I am not a CSS Nazi or anything along those lines, nor am I inexperienced in Javascript, but I wanted to take the long, scenic route to developing my framework using only CSS , so that I could include everythig in just one file and not have to worry too much about compatibility with user scripts. Also, when I say pure CSS, remember I mean anything that will result in a single CSS file, so preprocessors fall into that category and my preprocessor of choice is Sass (SCSS specifically), which I did use.

The foundation

Before starting, I had to do some research. This was crucial for two reasons. Firstly, I wanted to know my competition and their shortcomings. The second reason is to actually get some solid ideas about what people really want and use by comparing features and styles. That specific question was also asked on reddit and I got some good answers to get me started.

I focused on Bootstrap and Pure because they were the only ones I had some experience with and also because I felt like they were great representatives of the two sides of the coin that is the front-end framework scene. What I mean is that Bootstrap tries to get a lot of components and ends up in a very bloated state, while Pure tries to get just enough to be small and still work as a solid foundation. What I wanted to do is find the middle ground, or more accurately a middle ground as there is not a specific balance one needs to strike. My research indicated that I needed to develop with mobile in mind from the start and not go back and shoehorn it in later. Apart from that people love some common components, like grids, buttons and navigation components. Lastly, the more I looked around, it became apparent that everyone was using something like normalize.css, which sounded like a solid base for my work.

normalize.css was where I started, but with a twist compared to other frameworks. What I thought was that normalize.css sets a base which is very often overwritten later in the framework, so I went ahead and added the ability for the framework to customize about half the rules or so. This allowed my to get a solid start in terms of colors, fonts and general base typography rules, which usually takes up some space in a framework. Next up came the grid which was, as probably the most used component, the easiest thing to develop, as I found lots of great tutorials online. Next thing was the buttons and navigation bar, both with twists of their own to fit my specific needs. Tables, forms and more complex components like carousels and alerts were coded over time, but the base was there already.

That’s pretty much it in my opinion for laying the foundation of your framework. Start small and add the bare minimum modules at first. Try to stay loyal to your ideas and goals and you will have a decent base in no time. For a more in-depth analysis of the inner workings of a front-end framework and how I managed to fit all the features I wanted in a tiny space, check part 2.