Is that CSS framework really necessary? It depends!

[badlydrawnrob]

⚠️ This is important! But requires a proper article, really.

• Currently using ECSS in Anki Programming Themes, but ...
• What should we be promoting to young people?
• It largely depends on just how large your site will become!

This started out as a question, but turned into a bit of a ramble. I'm just laying out my thoughts that'll help me make sense of the landscape, and hopefully help someone else too. If you are learning CSS, I do think it's important to get comfortable writing it before you start using frameworks. In some ways they do reduce the burden and speed up development time, but that comes at a cost.

If you ever need to adapt, edit, or overhaul a website, and all you know is frameworks or no code systems, you're going to struggle when things break.

What frameworks are out there?

Tailwind/ECSS: two sides of the coin

There's a big who-ha about Tailwind at one end of the spectrum, and ECSS as it's polar opposite.

• ECSS requires a lot of duplication
  • Because you isolate each element (even if they're only slightly different)
  • It involves cross-referencing the code if two pages are the same, but for a few minor variations.
  • This is what happens sometimes on the Anki Programming Themes (two different cards, almost the same)
• Tailwind feels a bit wrong
  • As you're putting all the styling into the html.
  • You can use styles with a preprocessor so they live in your CSS (not in the html) ...
  • But that seems like a lot of work to figure out.
  • One good idea they have, is on reusing styles (and keeping that simple)

So it's a decision between isolation and abstraction where one allows you to delete elements with impunity, and the other allows you to keep everything (literally, everything, even hover:bg-sky-700 hover states ffs) as .classes you add to your HTML. Tailwind seems to have made a lot of money from the idea, so there's enough people who prefer it to prove me wrong.

So if you're wanting to build a UI with little knowledge of CSS and you just want to get it up quickly, there's a place for Tailwind. If you're wanting purity, give ECSS a look. I however, am beginning to feel both are a tad heavy handed in their approach — at least for smaller sites.

Bootstrap is (also) too big

Huge frameworks like Bootstrap are fucking awful. On the surface they look like they save a lot of work, and I've personally used this framework before (a long, long, time ago) but the problem you'll run into is dependancy hell.

1. Bootstrap updates and something will naturally break,
2. You'll have to race to make updates to your code (especially if upgrading to a new Bootstrap version),
3. You're adding a huge amount of code to what's probably a small website,
4. You Ain't Gonna Need It: (YAGNI) is a golden rule of programming:
   • Do the simplest thing that could possibly work!
   • Just-in-time additions as and when they're needed.

There's definitely an argument that frameworks as large as Bootstrap will speed up delivery, but there are a good number of lightweight frameworks that will do the job just fine.

Do the simplest thing that could possibly work!

CSS is quite difficult to get right.
You're not learning if you're not doing it from scratch.

So frameworks are handy, but not necessary. CSS can get difficult, but it's important to understand it — at least a little — before trying your hand at frameworks. The inconvenient fact remains that if you're using a heavy framework, you're not really learning CSS!

I'm generally of a mind to lean a little towards the brutalist mindset when designing — less is more — type of thing. Fancy UI is difficult because it often involves a lot of code and a lot of working with Flexbox and Grid for layout. You'd think that building a responsive menu would be easy, but it's actually quite tricky: Does it follow the page down as the user is browsing? How does it collapse? How many menu items are required? What about their hover states?

Alas, I forget about stuff with CSS all the damn time, and a good number of methods just aren't obvious in their approach. Take for instance margins: two elements with margins that are adjacent will collapse, so that their margins overlap. But not for inline-block elements. Why? Hell knows why. See it in action here.

So yeah, I have no great love for CSS! I can totally understand why people would want to take the "easy" way out with a framework — I'm a hypocrite! However, I'd still be on the side of simplicity whenever I have to use it.

A small note on separating concerns

There's a school of thought, and it may be an old school of thought, that the information layer (HTML) and the visual styling layer (CSS) should be independent of each other, even though one informs the other. Tailwind absolutely destroys this mode of thought, so although it might be faster to get a design off the ground, the code you have to use makes the dinosaurs gag. That font-size doesn't belong there! I can barely see the HTML for all those classes! And so on.

<div class="max-w-sm rounded overflow-hidden shadow-lg">
  <img class="w-full" src="/img/card-top.jpg" alt="Sunset in the mountains">
  <div class="px-6 py-4">
    <div class="font-bold text-xl mb-2">The Coldest Sunset</div>
    <p class="text-gray-700 text-base">
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptatibus quia, nulla! Maiores et perferendis eaque, exercitationem praesentium nihil.
    </p>
  </div>
  <div class="px-6 pt-4 pb-2">
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#photography</span>
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#travel</span>
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#winter</span>
  </div>
</div>

If you've got an hour to waste, do a Google search for "Tailwind is bad" and watch the flames burn. There's an army of coders that'll argue for both camps; good and bad. While I can understand both perspectives, I think the answer lies somewhere in between. Frameworks like Tailwind may be useful, perhaps for quick and dirty MVP prototypes where you don't want to invest much time; horrible for large scale and long-term projects with big teams and scores of juniors you need to train?

Whatever your position, just remember, life is short and I don't really care anymore. It's just not that important. Use what you want, suffer the consequences. Most of all, don't make the customer suffer your bad decisions. Don't make them think!

The hard parts of CSS

1. Refactoring code is time consuming (especially if that code is complected),
2. Design Systems become necessary with larger projects,¹
3. Many Javascript frameworks use components such as this one ...
4. ... but Elm Lang tells us to build data structures (not components),
5. I don't know which is better! Both are difficult!

Although separation of concerns is the ideal, in practice there's an interplay between HTML, CSS, and Javascript that's a little harder to separate out. That's what ECSS tries to do, by grouping those technologies into a component. That component would have a specific function or goal in mind (such as a form); most Javascript libraries like React and Vue do this too, and it seems to be an accepted modern approach. It can make life that little bit easier.

There's an exception to this rule though, as functional languages like Elm start with the data and have flexible views rather than components. This seems fine for smaller sites, but it breaks down a bit (for me) with larger projects, mostly because at that size I generally bow out: handing the project over to someone more competent! Functional programming is a purist approach, and it can lead to architectures that I find difficult to follow at scale.

I've always been more on the design and frontend side though. On real projects, you often don't have the luxury of choice. For example, I've been part of a project where the marketing team had the lead; using Hubspot's archaic templating language, trying to shoehorn in "pure" code which ultimately wasn't the teams priority. Taking a looser approach to CSS for a service that was short-lived; or focusing in on accessibility for a mental health website.

And these are the projects that still live, somewhere, on the web (thanks Internet Archive!). I don't profess to be a good programmer, but I think I'm an OK judge of what's useful and what isn't. 100% of my projects prior to 2020 are well and truly dead. The sad fact is, I think that's quite normal in the internet world.

So why bother with difficult, unwieldy, hard to maintain CSS? I'll take the simple path and leave fancy UI to the young dudes. I'm all for making good art so long as it's paying or making you feel good, but there's plenty of sites out there getting great hit rates which look like they've been knocked up in a few seconds.

So don't sweat the small stuff. Really, don't!

Smaller, saner, alternatives

Here's a few smaller frameworks that'll do the job just fine!
Aim to keep projects as tiny and simple as possible :)

• GPS: An interesting article about cleaning up the classes, yet still allowing for separation of concerns
• Pico CSS is a framework that aims to keep things simple with fewer than 10 .classes
  • You can even remove the need for classes completely

Footnotes

1. Design Systems are important for larger projects where you'll be working together with a team, as it stops you getting under other's feet. For smaller, solo, projects you only really need to throw a few elements on a page and you're good to go. There's accessibility focused design, such as the UK's Government Website, and design for websites and apps with Material Design of which elements are useful, but I find it all a bit "busy" and convoluted. There's loads more out there, so go find 'em. ↩

[badlydrawnrob]

No! It's not necessary! Maybe! It depends!

The missing.less and simple.less files are almost identical. They can be reduced down if necessary but while there's only two real files that use ECSS: leave as is for now. Just try and keep it simple wherever possible everywhere else it can be!