Actually we are using a framework its called ITCSS just a custom implementation of it which is how its meant to be used. The fact of the matter is there are very few frameworks out there, three to be exact which we will cover latter. In actuality you are most likely referring to a UI library more than an actual framework. The use of these lead to more blot to the software than is actually needed. Not to mention that they force your hands to use w/e coding style and implementations they adopt and update as they deem fit which is not ideal for large scale applications. Then there is the fact that most of the components we use are not in any of these libraries leading to custom code anyway. The fact is for the code we would need from a UI library such as bootstrap for example is about 10% of the code in bootstrap. Thats alot of overhead and becomes very difficult to manage from a development perspective. Not to mention that the code is not well organized, documented, or without errors. Its better to instead only use what you need from it to reduce that overhead. Which in turn allows us to improve upon it. This is actually the approach we took. For the core and every component I start by looking at a couple of these libraries to see if they have a similar component (forms for exp which is mostly influenced by bootstap base layer and material UI design layer). If they do then i will use that as a base to start with. But the fact is everything outside of the core layer is not represented by any and ends up piece mailed from multiple sources before i retool to what is needed. So if you look at the core.css which is the framework, 90% of that would be what you are referring to. But for arguments sake lets take the full core and utilities layers. Core is currently at 3.1k lines of code and utilities is at 142 lines. Lets look at bootstrap which is broken up into several files in the latest version bootstrap.css Which is 9,728 lines, bootstrap-grid.css at 3,951 lines, bootstrap-reboot.css at 425 lines, and bootstrap-utilities.css at 3,516 lines of code. So thats 3.2k lines in base-l unrefined with better structure and code quality at the moment vs. 17.4k lines in bootstrap which is bloat unstructured and not well documented, not to mention not a clean 1:1 plug and play.
Our approach has all of the upsides with none of these downsides. We can also easily plug and play a specific component in from any framework you want if there is overlap. You want to use buttons from materialize? Navbars from material UI? Forms from bootstrap? Just replace the scss objects in base-l with the one from them and rework the html...bobs your uncle. The main difference between all of these libraries for these objects is mostly code quality, naming and adherence to your projects coding guidelines. The fact is most of core is that way. There is not alot of difference in the code for buttons, tables, code blocks, navbars, grids and forms. It all boils down to code quality and ease of maintenance. None of the major UI libraries have good coding standards in place that make them easy to use in large projects. Outside of two actual frameworks you probably never heard of inuit.css and SUIT.css. SUIT suffers from odd choices is naming practices and a weird structure which makes it a hard sell. As for inuit its the purest implementation of ITCSS as its a repurpose of the original framework from the creator of both ITCSS and the original inuit.css. Its main problem is that it does a bad job of creating the base layer and does not fully align with our coding standards.
In the end none of it matters though as the main purpose for any of these is to speed up the development workflow, and ease of maintenance. The fact is when you boil it all down a custom approach is always better at handling both of these.
So all that leaves is customization to look at. And the fact is the use of any of these UI libraries makes it more difficult to customize not easier. Sure you may be used to their code? But the amount of bloat introduced into the html in any of these UI libraries would make maintaining the project a nightmare. None of them have any framework in place. Meaning there is no thought put into different layers needed to render any one component.
This is where
ITCSS really shines as it is an actual framework that does put thought into all of this. It makes understanding, working with, and maintaining the code simple. It defines layers that all our code fits into and naming conventions that help us to separate out our code, not unlike another framework you may be familiar with called
SMACCS which ITCSS bases its approach off of seeing as how it been around for ages. You get the benefit of clean controllable customization through the use of theme classes. It also has a better strategy for controlling css inheritance which is something that can not be said for any of the mainstream UI libraries. Which is one of the main problems with prosilver.
Looking at the html/css i know for any given component what code is responsible for the layout vs any utilities code while allowing for separation of the theme.
This makes for a very clean and easy to understand codebase.
Lastly all of this makes it far easier for us down the road to implement tools to make customization easier.