Modern CSS Layouts: You Might Not Need a Framework for That | Hacker News Reader

Modern CSS Layouts: You Might Not Need a Framework for That

smashingmagazine.com

59 pointsalwillis23 comments

Our application has been on an old version of Bootstrap. And for sometime we have been evaluating different frameworks and libraries as a replacement. But they all feel huge and complicated.

My CSS knowledge was still stuck in 2010, with a bit of learning since then. So after seeing some impressive modern one liners I decided to look into modern CSS and compatibility.

It took about a week to write a new, very clean and very simplified CSS style sheet to replace Bootstrap. We own it, since it is tailored for our app we don't need to use many classes (the HTML element defines the style). The sheet is about 1000 lines of CSS, 50 lines of Javascript, and supports dark/light mode.

First we replaced the navbar – a global element. Now we are replacing screen by screen with the new style sheet.

It uses modern CSS nesting – but we still run it through sass because enough customers are using Android or older versions of Chrome that don't support the nesting. Otherwise we haven't had any reported problems.

MDN is a fantastic learning resource for all of this.

We recently scrapped our old Bootstrap-like framework too, and also opted out of using any type of UI widget tooling.

Everything can be done so much more easily today with vanilla CSS and JS that it's hard to justify the overhead despite knowing there'll be a certain amount of customization work required to implement a good UI.

Still using a CSS preprocessor though, like you, but soon that will probably be gone too.

Neat, so you are running both bootstrap and your custom css file and js file in parallel on your app? How are you guys quantifying what parts to work on?

Anytime we make a change to a screen we opt to upgrade the CSS template. So, only if we are working on that part of the application.

Typically it takes just a few minutes to switch out the CSS.

Now, there are a few very complex screens that require more effort (a lot of data viz and variable state). Those we evaluate - maybe we will punt on the upgrade – or maybe we dig in and do it if there is nothing urgent on the books.

> but we still run it through sass because enough customers are using Android or older versions of Chrome that don't support the nesting.

How does sass help in this instance?

Sass variables and CSS Custom Properties (a.k.a. CSS variables) are pretty different from each other [1].

If you want to use CSS Nesting and be backwards compatible with older browsers, the PostCSS plugin postcss-preset-env handles that and lots of other new CSS features that older browsers don't support [2].

[1]: https://sass-lang.com/blog/sass-and-native-nesting/

[2]: https://preset-env.cssdb.org

Thanks!

sass expands the nesting ie

  .foo {
    .bar {
      color: red;
    }
  }

becomes

  .foo .bar { color: red; }

The first case modern browsers can handle, but versions of Chrome upto some in early 2023 still can't – and that includes a lot of Android installs as I experienced.

Once those browser versions roll off we will be able to remove sass altogether.

Thanks, I appreciate the answer example!

I'd divide CSS development into eras.

First there was the DIY Era, when layout options were limited and CSS implementations were riddled with bugs and browser differences. Most folks coded their own layouts using a small bag of tricks (e.g. float + clear-fix). It was messy, but it all fit in your head.

Then came the Framework Era, when lots more things became possible, but the size of the spec exploded, and with it the number bugs and incompatibilities. A common choice at this point was to use a framework.

This article fits with the idea that we've entered the Reference Era. Implementations have matured enough that browsers do what you want without arcane hacks and workarounds. You just need a good cheat-sheet, because the spec has long since stopped fitting into most peoples' heads.

> First there was the DIY Era, when layout options were limited and CSS implementations were riddled with bugs and browser differences. Most folks coded their own layouts using a small bag of tricks (e.g. float + clear-fix). It was messy, but it all fit in your head.

I call it the Neopets era because I first learned HTML from all the hacks people did to customize their personal pages.

I'm going to pretend you didn't just disrespect my friend Tom on the wide open internet.

Like the way there's a "You Might not need JQuery", and now "You might not need a CSS framework", I really can't wait until there is a "You might not need a front-end framework", "You might not need React", "You might not need a build step anymore", etc.

Every time you work in DRY, you save it for the next project and eventually open source it and it becomes a new framework, yay!

There used to be a YouTube series I think it was developed by Mozilla but I'm not sure, where they would show the kind of things you could accomplish with flexbox and CSS grid.

Basically anything you wanted.

I think what CSS frameworks offer tends to be more on the lines of consistency which I always struggle with when doing my own CSS.

css variables now make consistency fairly easy to support, since you can just define root level variables that change depending on light/dark-mode, etc.

This only works if your team is disciplined enough to make it work. It's always easier to reach for `4px` than remembering the variable name of the standard button margin.

But this is the basic paradigm I try to use most of the time too.

If your editor of choice has autocomplete it is the same or less work than using named standard classes in a framework like bootstrap.

My editor has autocomplete as a general feature. I've never seen one that was aware of css variable names across files though.

> My editor has autocomplete as a general feature. I've never seen one that was aware of css variable names across files though.

I'm using vscode with codeium. It autocompletes variables[1] across files.

[1] And almost everything else.

I use intellij and it is css-variable aware but not css class aware.

It's even easier using the light-dark() function [1].

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...

I might not need one, but I always tend to use one in order to shield myself from the absolute madness that front-end dev has been in the last ~decade.

To be clear, I'm sure there are "good parts" but the sunk cost of learning HTML/CSS in the 00's is something that I don't want to pay again, from a practical perspective.

If you have broccoli hair and you're new to this cesspool, of course you should learn the most recent stuff. I only ask you to take a few hours to learn what Internet Explorer was and how the web landscape was in the early 00s, now compare the current status with Chrome and get your conclusions.

Reply on news.ycombinator.com