Comment by jweir | Hacker News Reader

Comment by jweir | Hacker News Reader

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 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!

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!

Reply on news.ycombinator.com