Let me guess what type of dev you are and what type of clients you have. I can think of two types, you work on projects when the product is very customized, for a client or even for you or your company, but this is something where you need to create one single product. Or you can also be a developer where you need to create a product which will be redistributed. So, who are you? Let’s keep this in the back of our minds for now. I’ll try to tell you why in some cases you need UI framework, and why in some cases this could be a bad idea. Of course, like always, this will be just my opinion, you can agree or disagree, and please tell me why, in both cases. Oh, and I assume here that you have a little bit of understanding of how the most popular UI frameworks are built.
Let’s start from a little explanation. What did I mean when I split developers into two types? This is of course one big generalisation, but it really falls into the frame when we want to think about UI framework usage and benefits. But first – why do we need UI framework at all?
I’ve used many UI frameworks. Foundation, Bootstrap, ‘new Bootstrap’, Semantic-UI, Materialize and I even built one for myself. After these experiences I can tell you for sure - in most cases, I don’t need them. Let’s think about when I could need them first.
When I work for a client who needs only a starting point, I would definitely need UI framework. I need it because I am not sure how my client wants to use the code in the future. So giving him the code base which all front-end developers know is a very good idea. Let’s take a look at the example. I’ve done some themes for the Ghost blogging platform on ThemeForest. I needed to use some standards there because I also want to give future clients some tools to be able to quickly modify the theme without strong front-end knowledge. This is where usage of such tools like Foundation or Bootstrap is really great. What I need to do in that case is use most standard configuration and the most popular way of using these tools. What do I mean? In those cases, I try to avoid usage of many custom mixins and customizations. I use standard structural classes which these tools provide and I don’t change the standard settings much. Of course I do this partially, but only in the context of the themes styles. This way, my client is able to quickly jump into the code and start modifying it. When I use some custom classes described by many mixins from the framework, my client will probably overwrite it all in some other place or he might also remove them.
Ok, so this is a very good example why we would like to use the UI frameworks. You’re probably thinking, ok so why we don’t use them the same way in other projects. What is the problem? That’s a great question. Of course you can, but I want to tell you why that might not be the best idea.
How many times have you wanted to customize your buttons using the UI frameworks? First of all, you need to find all needed variables in the .scss files and then you will probably need to overwrite some styles because they don’t have the variables for that. Next, you need to create some custom variables for your custom buttons, and then all variables are unreadable because you have some overwrites from the framework and some of your custom ones. Or maybe you wanted to use clean tables on your site and it appeared that they are styled already so you need to switch off all the styles. These are just small examples. Imagine what a really big project would look like.
You don’t need to use buttons from UI framework if you don’t want to!
Yes, you’re right, and it’s a useful feature to be able to remove some parts of the framework, but then hey, it might appear that you end up with almost all custom styles without even using the framework.
The next very important part, which is sometimes a good reason to use UI framework, is the grid system. There were many projects when I got the feeling that I did’t need any UI framework but I needed the grid. That’s why I wrote my own grid. Now I also think about this. When I built my grid which uses Flexbox, I started thinking why not just use native Flexbox instead. I liked the grid because usage was very simple, but when you use something like Autoprefixer, using native Flexbox is also very simple. Not to mention that soon we will have native CSS Grid standard in the browser. So why would we need that from the UI frameworks?
The other example – let’s assume that we use React on the front-end and the first thing is that we want to find the grid for React which could be used as styled components, right? I can think of React Bootstrap or Semantic-UI for React. Why? This isn't the simpler way. That’s a hard way to achieve a simple thing. I can’t understand that. Why we can’t just use well structured class names and custom styles for that. Maybe using CSS Modules etc. I guess I’m not a very big fan of styled components. Of course it's always better to create one styled component if it is in use all the time, but we can do this without UI framework. The other thing is performance. We usually import only a couple of components from big libraries without even knowing how big of an impact it has on our app's performance and we even don't know how to customize these components anyway.
Ok, so let’s assume that we don’t need UI framework because of all mentioned above cons. So what could we do with it?
From my experience, I figured that it would take me much less time to write my own custom and reusable buttons, mobile menus, and so on, than finding the way to customize the existing ones. When I want something much more complicated, like, for example, the carousel component I can take one from many available for my stack, there are components for React, Angular or jQuery. There are plenty of them on the Internet. Of course if I have some time I can write one for myself and, if I do it right, I can even use it in my many different stacks. What are the benefits when using just custom CSS/SCSS configuration? You get code which is clean and very readable. You can use your naming conventions in every stage of the project. You can use semantic names for the classes. You can use your own mixins and reusable functions. Most importantly, your css codebase will be always smaller and you’ll use only needed stuff. The only thing which you would need is some kind of standard to reset your CSS styles. It could be, for example, Normalize.css project, which is also used by many UI frameworks. You can add it by yourself. Just one CSS file.
Very simple right? Not really! What if after me another developer comes. How he will find himself in the project if there is no Bootstrap-like names for classes in the HTML code? Very good question. But I think (and it should be obvious) that if this is a good developer, and the custom code structure is well designed he will find himself very quickly. He will find the _buttons.scss or _forms.scss files, he will also find the _utilities.scss file, even if this isn’t a UI framework configuration. He will also find how to use custom mixins and functions. He will be able to add new ones without thinking about any external toolset. And maybe it will be even simpler for him to find all the pieces.
If done well, well-parameterized, built with reusability in mind, custom CSS/SCSS stack could be much more usable than any of UI framework out there. You can build your own base of styled components, mixins and functions moving the codebase from project to project. Of course using only the parts which are really needed. You don’t need to do this at once.
When you build some starting points for your clients, you can of course still use Bootstrap or Foundation. But maybe the client will agree to your toolset too if you convince him and show the demos of your work.
I guess we should always think about it and choose the most optimal solution for every project.