Modern web user interfaces often are single-page applications (SPAs), written in JavaScript, based on frameworks like React, Angular or vue.js. But what is rendered in the browser is still good old HTML and CSS. Therefore, even in times of SPAs, as at the beginning of the web, markup for wrapping the actual content must be written (HTML). As well as there have to be rules for how the contents are positioned and styled (CSS).
Different Approaches
In writing HTML and CSS, there are basically two different approaches:
- Handcrafted: HTML and CSS are written completely by hand from scratch
- Off-the-shelf: HTML and CSS are provided by a frontend-framework, which usually comes with some customizing options for things like colors, fonts, font sizes, etc.
Well-known frontend-frameworks are, for example, Bootstrap or Foundation.
As frontend-frameworks became a part of the web developer’s toolbox, the decision whether to use them or craft HTML and CSS by hand had to be made. But keeping in mind the previously mentioned SPAs, we additionally have to think about components …
Components
SPAs are composed of combined and/or nested components. You can think of a component as a bundle of HTML, CSS, JavaScript, integrated with content. Common examples for components are tab-bars or modals. When it comes to components, the decision is the same: handcrafted – write and style components from scratch – or off-the-shelf – use a component-library like Material Design or Semantic UI.
No matter which option you choose, handcrafted as well as off-the-shelf solutions both have some traits and implications. Depending on the kind of project you are working on, these traits and implications can be advantages, disadvantages or irrelevant.
| Handcrafted | Off-the-shelf | |
|---|---|---|
| Cost of Development | All frontend-code is written by hand; it takes more time and effort. | You can start with the given markup right away and don’t have to touch CSS. |
| Overhead | The browser will only load what you have written. If you have written clean frontend-code, there will be no overhead | Always results in loading overhead; even if you can use only needed modules, there will be unused code delivered to the users browser. No framework allows for such detailed customization that you can totally wipe out overhead. |
| Customizability | In handwritten HTML and CSS there are basically no limitations, but already existing code (legacy!) can result in disproportionate expense. | Depending on the frontend-framework, there can be different customization leves: very, roughly or not at all. If you have to touch a frameworks CSS directly, you usually shut down the possibility to update the framework to future versions. |
| Maintainability | Directly related to the quality of the written code. | Usually, frameworks/libraries aim to be backward compatible and therefore updates normally are no big deal. |
How to Decide?
As you might have noticed the major twist between handcrafted and off-the-shelf is that off-the-shelf solution can deliver results much faster, whilst handcrafted user interfaces are a lot more flexible and customizable. Depending on your project, you should choose the better fit.
Let’s Take a Closer Look
When using a framework for (very) small projects you will probably run into a lot of framework-code that is not used. This means lots of overhead.
Overhead is also an issue when you use a framework and make heavy customizations, individualizations or extensions. From my experience, I can say that when a project started making essential changes to a framework, the chances are big, these adjustments lead to more adjustments and workarounds (broken window effect). At some point, the rendered code often consists of more changes than actual framework-code and therefore huge parts of the framework are basically unused overhead.
Maintainability
Heavy framework adjustments also result in code that is hard to maintain. Especially when adjustments or workarounds are made in areas of the framework that are not meant to be changed. New teammates won’t expect changes here and will have to dig deep into the code to understand what is going on. That’s time consuming, frustrating and not effective. Besides, performance is something that really suffers from extensive adjustments.
Especially when you think of CSS-specificity: to overwrite CSS coming from the frontend-framework you often use lengthy selectors that must be compared with the corresponding selectors of the framework by the browser. Therefore, rule-matching becomes significantly slower than it needs to be.
Small project size and the need for heavy adjustments are two points that – for me – oppose the use of a framework.
But when you have to move fast with a project and it’s ok for it’s UI to not look one hundred percent customized, off-the-shelf solutions are a perfect fit.
Examples
Let me give you some examples: I would not recommend using an off-the-shelf solution like bootstrap or material design for small websites with very little content or product websites/shops/you name it, that come along with an elaborated design and very unique visual language. On the other hand, I would go for off-the-shelf solutions for software that is meant for internal use and specialist applications. Those kinds of software tend to be very form-heavy and there is no need for a perfect, individualized look and feel. Here, UI-frameworks really can boost development.
Surely, when it comes to deciding for handcrafted or off-the-shelf, there is no right or wrong. The mentioned factors are certainly not the only ones that affect the decision for using a frontend-framework or not.
But in any case, the decision about where HTML and CSS come from in your project should be taken carefully and with providence.
Schreibe einen Kommentar