Why SHUT?

As all frameworks (or libraries if you may), this started from the necessity to control repeating patterns of design and coding. Naming CSS before css processors, was very crucial, maintaining them was not easy. Shut framework was conceived in around 2004. Yes. I am a procrastinator.

The case against Bootstrap

Bootstrap provided developers with a stylehsheet that allows them to draw anything, in HTML. Literally anything. Developers can control paddings and margins, background colors, borders, and a lot more. This, was not ideal, because it took the responsibility of maintaining site style out of stylesheets, into HTML pages. It created chaos.

Naming in Bootstrap is data-driven (sometimes), meaning, "btn-danger" is not always used for "danger" related options. Making a distinctive different looking button is a design option. CSS is not supposed to describe data, rather style, or choice of style. (For example, box-red, or box-light).

Detailed styling, over-loads the outcome stylesheet. SHUT framework provides enough for designers to quickly prototype, but to add style, and look and feel, they should roll up their sleeves and get their hands dirty. The output stylesheet is always smaller, and if done right, more maintainable. Bootstrap is a black box, hard to control, or maintain, let alone customize.

When Bootstrap came out, a lot of designers found refuge from obstrusive libraries (like Kendo UI), where they controlled the HTML, and let CSS be what it is good for; styling. Unfortunately, as the years went by, Bootstrap became yet another UI component library with an overloaded HTML hierarchy, and a huge CSS stylesheet to maintain. This lead to many derived libraries trying to control the output by simply wrapping it inside mroe black boxes!

The main take against that is maintainability on large projects. If you do not get the same HTML you wrote as a developer, fixing style issues becomes a nightmare. That actually is why I do not buy into web components, just yet.

SHUT is to prototype.

Shut framework was first built with one target in mind: I am a designer, who wants to create a quick prototype, that can be used later to develop real code. I do not want to throw it all away and start over (as we do with prototype apps), and I do not want to dig too deep into the engine to customize it (like in Bootstrap). I aslo want to own the HTML output.

The case against prototyping apps

The first online prototyping app I used was InvisionApp. Great app. Today I use Figma as my design Adobe-alternative tool, basically for everything. Except prototyping.

Knowing how to code myself, I admittedly never tried to dig deeper into those apps' ability to create code. I just didn't care enough.

In addition to that, my fingers hurt after a couple of hours moving and clicking the mouse to align things on screen! Am I becoming the grumpy old neighbor?

My argument: just as Bootstrap caters for developers who do not design, those apps cater for designers who do not develop. They may have some coding skills though. But if you know how to code like I do, you would feel absolutely limited by those apps. So if you know how to code, CODE your prototype.

Developers are color-blind

My cynical comeback to developers trying to design something out of the box. Developers who do not design, should not be given the power Bootstrap gives, they will most definitely screw it up. Stopped counting the number of times I was asked to “clean up and fix” code that went out of control, that was built by Bootstrap.

SHUT, the world between.

Somewhere between Figma, the awesome prototyping tool, and Bootstrap the awesome CSS framework, lies SHUT.

Why was it called SHUT?

Why not?