Stepping Away from Sass | Hacker News Reader

Stepping Away from Sass

cathydutton.co.uk

211 pointsspking155 comments

The case for CSS variables is interesting. I'm still trying to figure out the best way to integrate them with a CSS framework I created, called Bulma: https://bulma.io/

There's a few ways to combine Sass variables and CSS variables:

  - make all Sass variables available as CSS variables as well, so $primary will also exist as --primary  
  - assign a CSS variable to a Sass one: $primary: var(--red)
  - assign a Sass variable that was defined as a CSS one: $red: var(--red) and then $primary: $red

Color functions are one aspect that isn't well supported yet by CSS only.

There's also a more "philosophical" question: why offload the variable resolution to the client side when it can be done at compilation time? If you're not gonna update a variable's value at runtime, it doesn't really need to be available as a CSS variable.

It's like single page apps that always render the same content, and are better off rendered once on the server side and delivered as static HTML, instead of being rendered thousands of times by each client.

But to be fair, CSS variables have other benefits, like creating color variations very quickly:

  // Sass
  .is-success
    background-color: $green-invert
    border-color: $green
    color: $green
    &:hover
      background-color: $green
      border-color: $green-invert
      color: $green-invert
    &:active
      background-color: $green
      border-color: $green
      color: $green-invert

  // CSS
  .is-success
    --color: var(--success)
    --invert: var(--successInvert)

Even with CSS variables, Sass still has a lot of benefits listed by other commenters here, like reusable mixins and nesting. And one of my favourites: @extend!

I just want to say thank you for bulma, it is a top notch project and I recommend it to everyone.

> why offload the variable resolution to the client side when it can be done at compilation time?

Imagine I have a property that I need to change depending on screen resolution in order to make a responsive layout.

In my CSS rule I specify it to have a fallback default and to take a CSS variable that over-rides it.

Elsewhere in my CSS I define the CSS variable with a media query.

The CSS rule is quite clear in that it shows that something changes or can change.

In the olden days I would be declaring the CSS rule twice. Once for the default and once inside the media query.

With the old fashioned approach it would not be clear looking at the CSS rule that it had an over-ride somewhere else in a media query.

By using the CSS variable with a fallback in just the one rule I know that something in the rule changes. I can easily find the CSS variable, regardless of how it has been scoped to see what makes it get set. Since I know the convention for most of the CSS in the stylesheet, e.g. mobile first, I can guess that the variable is for the desktop setting.

The advantage is that I have code that I can hand on to the next guy and feel happy that even if they are not yet up to speed on CSS variables they will be able to easily work out what is going on with individual rules.

There is no point in Sass variables now, they are defunct. All of the functionality is superseded and there is no point learning two ways to achieve the same task when you can just master one. This trumps any 'compilation' speed ups, resolving variables is something that does not slow page load times.

The only use case for not using CSS variables is if you have to support people using extremely old browser.

>why offload the variable resolution to the client side when it can be done at compilation time?

So I can use Stylus to override one CSS variable and change the appearance, instead of having to save the website's entire css file, find all rules set to the "variable value" (aka a particular font stack), and redefine every rule to use my personal font stack.

Does a preprocessor really complicate the workflow?

Variables are still new and not fully supported.

Being able to nest css selectors is major win for me.

Reusable mixins is another.

I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

I still use less & sass on most projects, but it's occurred to me that:

* Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes).

* Nesting selectors save thinking and some typing regarding where styles cascade out to, but... tbh, yanking a high-resolution selector into the buffer and chucking it out onto another line was never a burdensome part of my pre- processor workflow.

* Pretty sure free-use of nested selectors and mixins is trading larger CSS files for developer attention (which may or may not be a valid trade).

* Variables... yeah, they're handy. Search-and-replace only goes so far. IE seems to be the holdup.

For small or disciplined teams with the freedom & skill to really think about their CSS starting from a style-guide-first perspective rather than every-page-a-custom-layout perspective, I can see making the choice to do without. Especially if you've already ditched IE 11 support for other reasons.

Writing pure CSS and copy-pasting things here and there is easy when you start.

Where SASS shines is when you need to do a coordinated change, e.g. these things become gray instead of black. You have a ton of black things so no search and replace. And once you've painstakingly determined and edited the classes, the hard part is to be sure that you only changed what you had to, and nothing unrelated.

SASS preserves semantics which plain CSS is unable to express. It's like C vs assembly.

You mean variables?

Because I've seen sass refactors go just as badly.

I just looked it up and css variables are available on all current version browsers and have been available since about 2016/2017

90% of users, which is a bit low for a lot of organizations.

They also aren't a full sass/less replacement, just one aspect

Nesting is by far the biggest driver for me. I can do vanilla CSS in my sleep, but it's such a cognitive drag.

I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.

How come I haven't experienced these downsides?

I'm with you. My SCSS is really just CSS with nesting. My CSS is cleaner without any downside. I've never experienced issues with maintainability, even in large CSS files.

That's where I am on this. Before nesting I had to take great care to avoid conflicts. I guess this is what BEM set out to solve, but it seems to have limitations.

Why would sass have any effect on whether or not you have conflicts? You can just do things in plain CSS with descendant (' ') selectors, same as if they were nested in sass.

Sure, but that's a bit like arguing that you don't need 'scope' for your variables and you can just prepend the function name (or multiple nested function names). Or that you don't need modules but can just put all your code in one file.

At the very least support of nesting is a huge convenience, but in practice I've also found that it saves me from all sorts mistakes, whether it's because I'm being stupid, or refactoring things.

That said, overusing nested selectors can be a problem too. I generally try to limit myself to two levels of nesting (component -> element), and then a third for pseudo-classes (:hover, :selected, etc.) and pseudo-elements (:before, etc.).

Probably for the same reason some people don't see the downsides of C++ or Java... you tend not to see the downsides, if you're good at it.

I just feel that nesting (which Sass encourages) leads to complexity and fragility.

As with everything, don't overdo it and you'll be fine.

I generally stick to only 1 level of nesting - I still find that really beneficial.

Hi, you seem to be the leading critic of nesting on this page, so I have a question for you.

Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS?

When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents:

    .MyComponent {
        // all the css specific to MyComponent
    }

Without nesting, how do you keep your component-specific CSS from polluting the rest of your app? Do you scope every rule every time? Isn't that tedious?

Thank you, I'll wear the title of: leading critic of nesting proudly! disclaimer I'm not a hugely experienced programmer, but have done a few open source projects in Vue, React and am currently working on a series of Angular applications with a team at work.

In Vue and Angular component styles are automatically encapsulated at the component level by scoping (I think) so nesting isn't really necessary to target specific components. Angular also recently deprecated a method of breaking out of component styling and soon it will be completely removed from the framework.

Although I'm a critic I'm not totally against nesting, I just feel that SASS encourages it, so without discipline things can get very complex and fragile. One level of nesting is OK with me though I suppose...

without discipline things can get very complex and fragile

In what way(s) is SASS different than anything else in this regard?

True, this could be said for any system, but in this case SASS makes it easy to create nested relationships, whereas CSS makes it hard.

Not OP, but you could use CSS modules, styled components or styled-jsx, all of which auto-generate unique classnames (styled-jsx uses a HTML attribute for it, I think).

I see.

These solutions all seem quite a lot more complicated than nested scopes! And at least for styled components (angular, I presume) and styled-jsx (react), they're framework-specific. Why are these solutions better?

Nesting is bad, because moving any element would break your style. And there's also performance impact.

I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.

There's no performance impact. Styles are precompiled locally before deployment.

There is, at runtime browser needs to do extra matching.

https://stackoverflow.com/questions/13829959/nested-selector...

It's about Less but the same rule applies to CSS and Sass.

Note the date on that. It’s my understanding that with modern browsers, except in pathological cases, selector performance is pretty much a non issue.

BEM is just an awkward workaround for the lack of nesting.

You’re manually creating nesting hierarchies and naming them (something a computer should be doing).

And yes, the moment you move something, everything breaks. Because instead of moving/renaming just the parent selector you have to move/rename all the related child selectors.

No what I mean by move something I mean adjust HTML structure, and deeply nested stylesheet means less flexible code. You can move anything within a BEM block without breaking style, instead of couple the CSS and HTML structure, which doubles every change.

And BEM is a workaround of names pace, not nesting. Nesting is not what CSS lack of. Instead what CSS really lack for is basic abstraction like function (same as function component in react to HTML). Given CSS is basically similar to key value pair (data), a first class function model would solve most of the problems - reusing, encapsulation, abstraction etc.

When we are talking about nesting we are not talking about generating `.page #left-section .box .button {}`... This would be bad. Nesting used properly is something like `.myWidget .button, .myWidget .title, .myWidget .main-section {}`. You can then move .myWidget anywhere you want and the styles would follow.

Nesting is only an asset with thoughtful consistency. There are so many different ways to organize a stylesheet with nesting it can easily become unruly. But I like it now because I've found a method that works for me while also cleaning up my html.

In some cases I can preclude the necessity of having to declare class names.

section {

  h1 {},

  p {},

  img {},

}

In other cases I have an index with easy-to-find classes.

.hero {

  .gradient {},

  .description {},

  .signup {},

}

EDIT: I meant to reply to a different comment but oh well.

> vanilla CSS

Is there another kind of CSS?

You know what I mean, Sheldon.

My point is, one need not apply an adjective to something that does not need qualifying. Just like "vanilla" JavaScript. You are either using JavaScript or you're not but people have been doing that for years and now I see posts asking for definitions or differences between "vanilla" and other flavors of js.

Terminology is important but I see it's not important among some people and other hobbyists online.

I can't speak for the others, but when I use the terms 'vanilla JavaScript' and 'vanilla CSS', the distinction I'm trying to make is that I'm not using any libraries or frameworks.

There is a meme within the community about 'vanilla JavaScript' called VanillaJS:

http://vanilla-js.com/

https://stackoverflow.com/questions/20435653/what-is-vanilla...

Saying I'm using JavaScript is sufficient. Or stating "I'm not using any libraries or frameworks" works, too.

This is a weird thing to argue about.

The overwhelming majority of front-end projects and developers that I encounter use some kind of library, framework, or compilation/build tool. It's common enough to basically be the default.

If you use 'plain' or 'vanilla' javascript (or CSS), you're doing something less common, at the very least around these parts, and so qualifying this makes sense. The mere fact that many people clearly seem to feel a need to point this out makes it so. Why would they otherwise?

Judging by your comment history, the vast majority of your contributions here boil down to some kind of dig at how 'people these days' are 'doing it wrong', and how obviously you are superior to that and how you don't see the need for any of this new-fangled stuff. I'm honestly curious whether that's just role-playing, or if that kind of superiority about being older and wiser is somehow important to you.

I'd very much prefer it if you shared the wisdom you've accrued in a more constructive way, because as far as I can tell you're not actually wrong about a lot of this stuff.

Older and wiser curmudgeons have played a valuable role in my development, but your approach strikes me as self-serving and somewhat poisonous to the/any community. But of course you're free to do as you please.

I don't care if you didn't need it, because it's helpful for clarity regardless.

https://stackoverflow.com/a/40115909/135845

Unfortunately, I see that "The Ubuntu Web Team" decided to shit the bed and steal the name for the CSS framework they created. So fsck me I guess.

Don't forget that SASS lets you use sane single-line comments prefixed by a double-slash. Heck, I'd use it just to avoid the laughably terrible /* CSS comment syntax */.

It works in practice though, because there’s no CSS syntax that uses //, so you can basically turn off any line that way by causing a syntax error. CSS fault tolerance makes it just ignore the line. Not sure if it’s wise to do this, but it works.

That’s a valid point. I’ve never actually tried it, because my editor always tells that it’s wrong. I suppose I could edit raw CSS with my editor in SCSS mode and just be careful to not use any incompatible features. :)

>>Does a preprocessor really complicate the workflow?

I've just spent yesterday getting sass to work with my Golang project.

I used to have a nice simple makefile task, that compiled the project (in a split second) and launched it on localhost so I could find out where the problems were. My only dependency was the Go compiler. If I changed the css, the next page refresh sorted it.

Now I have a "sass watch" task, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to.

I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application.

Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security.

So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.

Use sassc and call it from your makefile.

Not sure what it's like today, but last time I tried to use sassc it was a nightmare. The official repo was just the library with no CLI. I couldn't find a CLI that didn't also require me to compile it myself. Very frustrating.

You might be thinking of libsass. sassc is dead simple and solves all of this users issues.

Correct me if I'm wrong, but doesn't sassc require the user to compile it?

You're right, on OSX you can brew install sassc

there's a Debian package :) thanks for the tip :)

just got this working with fswatch and sassc, thought I'd feed back that this is perfect, thanks :)

Heh, I just woke up and read this and thought “well thats enough problem solving for today” :) Glad we could help you avoid the hell that is adding npm to a non-node project!

Another thank you from here! I've had to use node just for sass in the past and this is a much nicer solution.

You have to compile it, just like this poster has to compile their go code. There are usually packages and formulas for it in most std repos.

So a tool to fix the tool that's supposed to make things better.

Huh?

SassC is just a cli tool that uses the C-language SASS library. It's an alternative to using whatever ridiculous NodeJS solution was/is being used.

> I can assume that it's not injecting malicious code into my application.

You don't need to assume, npm has an audit command that helps figure out if any of your package dependencies have reported vulnerabilities: https://docs.npmjs.com/cli/audit

Does Go?

useful, I didn't know about this. Thanks. How does the reporting of vulnerabilities work for npm?

No, Golang doesn't, but then it doesn't have a registry like npm in the first place. Gophers tend not to use third-party libraries if at all possible.

isnt it very common to use github repositories as a library? I seem to recall that this was the way to get libraries, though it has been a few years since I looked into go

yes, but there's not an actual "registry" as such. Just a bunch of sites that have "useful go library" links.

> Gophers tend not to use third-party libraries if at all possible.

That sounds weird to me. It's pretty rare (almost never?) for applications to do useful things without third party libraries. eg any database access, input validation, making sure HTML output isn't malicious, etc.

Maybe that's just me though?

Go has an awesome standard library that does most stuff.

There's also a set of "semi-official" libraries for things like crypto that can't be written by amateurs ;)

There are some other libraries that are commonly used, but you can count them on one hand.

I'm a massive convert to this. Instead of spending my time working out how to get two 3rd-party libraries to talk to each other, I spend my time writing domain-specific code. and my debugging time is spent in repo's that I have a hope of understanding because I wrote them ;)

It doesn't suit everyone, and there are frequent rants on golang forums about people not importing dependencies. But every gopher seems to go through the same journey, and end up at a place where they just write their own code rather than importing it.

What's even more weird is making every 10 line function a "library" and the average program having 500+ dependencies. JS people are so hung up on "re-usability" that they completely miss the concept of dependency hygiene.

The process is explained here: https://docs.npmjs.com/reporting-a-vulnerability-in-an-npm-p...

I've been using the ruby Sass gem instead of the NPM version (https://sass-lang.com/ruby-sass). That prevents having to do the whole node thing. I know they say the ruby version is in maintenance mode, but for 99% of the use cases that's fine, it's been battle tested for years and Sass doesn't change that often anymore.

I find that https://github.com/wellington/go-libsass is usually good enough for Go projects.

yeah, I looked at that, but a few things put me off (unmaintained, old version of scss, some caveats in the readme, etc).

Just got sassc working instead, so happy again hehe

CSS variables are actually superior to SASS variables because you can change them at runtime via JS.

It does not. With Parcel for example it works out of the box and it even installs the dependencies automatically for you.

I still love SASS since it solves many existing problems at once like you mentioned.

in isolation, no, but the problem I've seen is that literal dozens of preprocessing steps for a javascript project, and these add significant cost over time.

In a corporate environment, too, you need to proxy many of these, and set an environmental variable in the shell for SASS to install properly. Over time, this adds significant cost, pain, and stress to the install process.

Nested CSS selectors should be counted as a major win for everyone - to the point where there's proposals to support it in native CSS: https://github.com/w3c/csswg-drafts/issues/2701

My personal solution to avoid running watchers is to have a run-on-save task in VSCode that automatically compiles any "root" .scss file (eg */index.scss) into a .css file with an accompanying .css.map file.

I honestly have never seen the value in pre-processors when writing CSS. I think they abstract a lot of low-level understanding of your UI and make your stylesheets overly complex. They definitely keep things sane when doing CSS at very large scale (for example dealing with color palettes, fonts, etc) but are not that useful when you're writing different components with different rendering needs.

Nowadays I just do functional CSS (Tachyons, Tailwinds, Fractures, etc). It has some drawbacks but you can go faster and change things more atomically without breaking everything when changing a class, and you have the safety given by the fact that every property have the same level of specificity (which can be overriden by JS generated style attributes, in case you need to manipulate the DOM directly)

Also, you can address your rendering needs atomically which works very nicely when you're writing components in isolation. They also are an excellent approach when doing server-side rendering since you can store classes combinations in variables that can be passed from one template to another or used and overriden in the same template as it gets evaluated by the server. It's almost like a pre-processor without the hassle of recompiling your sheets.

> I honestly have never seen the value in pre-processors when writing CSS.

As mentioned, theming and consistent ux requires far less writing and copy paste with a preprocessor than in pure CSS.

I think React's approaches make CSS feel simpler but often just sweep the inefficiencies under the rug.

A lot of this is being fixed with CSS4, so these will go the way of jQuery. And while you don't need jQuery today, it served as an important polyfill for a long time.

> A lot of this is being fixed with CSS4

CSS4 won't have nesting. SCSS isn't going away as long as nesting isn't a thing in native css.

(Also css variables are awful to use. Honestly, CSS-WG should have just copied most of scss's syntax)

I agree about CSS variables.

I'm unsure about the merits of nesting. Tends to make for some hard-to-read code.

Most nesting I do uses the '&' parent selector, so it's not "real" nesting.

  .a-long-class-name {
      background: firebrick;
      &:hover {
          background:  red;
      }
  }

This approach has some clear benefits (less verbose and it groups related code together) with little or no downsides.

Same, but this can definitely get long, ala

& > div, & a, & a { &:hover } etc.

Your example is a bit confusing. This would be a more idiomatic way of writing it:

  .some-class {
      > div, a {
          background: blue;
          &:hover {
              background: red;
          }
      }
  }

The solution is to not write css like this... ;)

Compared to BEM's .b-text-input__text-field or .b-select__option_selected or .media__img--rev nesting is a concise readable breath of fresh air

So you still type all this,

  .selector .child_one,
  .selector .child_two {
     color: #000;
  }

instead of,

  .selector
    .child_one,
    .child_two
       color #000

I no longer type a semi colon when developing a web site thanks to preprocessor and transpilers.

A lot of folks here are saying that they couldn't live without nesting CSS selectors.

FYI the CSS Working Group approved a working draft of native CSS Nesting last month; it's in "stage 1."

https://drafts.csswg.org/css-nesting-1/

There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting

when I use sass nesting it's almost always to do BEM style selectors via `&-`, which really is soo much easier to read than having to type the full selector every time, especially when you have A LOT of components in a directory structure.

sadly this use case seems to be missing from the coming spec :(

Agreed. This is trivial to add if you use postcss (postcss-nested)

Correct me if i'm wrong but postcss is js or node.js only, where's sass is trivial to add with any language.

I'm not totally sure but I think that for Sass only you'd still need Ruby or Node.

Sass has LibSass which is a C++ port of the Sass engine (which was originally written in Ruby). There are wrappers available in many languages, such as Go, Java, Node, PHP (and even Ruby, interestingly enough).

https://sass-lang.com/libsass

https://github.com/w3c/csswg-drafts/issues/2701#issuecomment...

> Yeah, very intentionally not allowed. It causes parsing issues, for one (you can't arbitrarily split up an ident and be guaranteed that both halves are still idents), and it's grammatically ambiguous with tagname selectors.

There's an open issue https://github.com/w3c/csswg-drafts/issues/3748 "add note explaining that BEM `&__element` class accumulation isn't supported and why"

Preprocessors like Stylus has all you want and in a better way (ex : variable declaration).

I already have something better than CSS in 5 years when most browsers in the market get the newer CSS, so I don't see a point in following CSS now.

Better to spend time making the preprocessor more accessible to developers.

I read somewhere a quote like, "a bad abstraction is worse than none at all." And for that I'm always on the lookout for things that look the same but aren't actually. Careful not to merge them via abstraction because they might deviate heavily all of a sudden and now you have to refactor a lot.

CSS is the #1 place where I spot those cases. And I feel that Sass and other CSS preprocessors mostly lend themselves to shooting yourself in the foot with abstracting similar things that aren't actually of the same category.

Well said, creating good abstractions is hard and takes careful consideration. Hopefully the abstraction has some kind of benefit; simplicity, flexibility or extensibility. I've personally found SASS to be cumbersome with the encouraged nested of CSS and tightly couples the CSS to the DOM markup.

A better abstraction in my opinion is a utility CSS library like Tailwind.css. It feels strange at first, but compose-able utility styles eventually feels like a good abstraction, with less shots to your feet.

> A better abstraction in my opinion is a utility CSS library like Tailwind.css

Exchanging sass with postcss based framework in my book is the worse abstraction for almost any purpose.

Why is that? Have you used it for significant projects? I've found the hierarchy of CSS classes and where they're defined (e.g. global or component) become hard to to manage and refactor when you want to reshuffle components around...

I feel postcss-based styling is simply more predictable and easier to refactor. And the abstraction, which can be clunky at first, becomes a sort of intuitive DSL which let's you develop faster...

Duplication is better than wrong abstraction... is probably what you meant to say

The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. I really wonder why they haven't been made native yet.

PostCSS [0] can do this and is far easier to install.

https://github.com/postcss/postcss-nested

Not sure how the install could be easier than "get a single command line tool and run it against your root source file". If you're talking about the Ruby version, node-sass doesn't require any of those extra steps

Have you ever tried to get libsass installed on a CI server? Painful.

Nope, though you're generally supposed to use a project that uses libsass (of which there are many), not use it directly. If the issue is the binary itself, then maybe the Ruby version is what you want after all.

That's not the point. Installing via a library is actually worse. NPM will bypass proxy settings via the postinstall script.

My point is that the libsass library should be ported to WASM to ease the installation in a CI environment.

Everyone forgets that SASS is meant to be programmable CSS.

It has loops, functions, namespacing, arrays, maps, and tons of utility functions (especially around color).

If you treat it as CSS+ then you're not really benefitting from it's true potential.

> Everyone forgets that SASS is meant to be programmable CSS

That sounds like a solution looking for a problem... The vast majority of real SASS I've seen has been much like the stuff this article mentions.

> If you treat it as CSS+ then you're not really benefitting from it's true potential

People aren't looking for "potential", they're looking for a way to accomplish their design goals whilst keeping their stylesheets maintainable. The real use cases where SASS is actually worth the complexity overheads are getting fewer and fewer.

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in productivity was wasted once I had to fight the framework for the fine details, and just writing what I wanted in vanilla-land ended up writing out the frameworks as a byproduct.

Is this a common pattern in industry as well?

JS, no. A hand rolled framework is going to be a hindrance the more feature-ful your site becomes.

OTOH, css frameworks go the other way. The more you have to do, the more apparent that bootstrap etc. get in your way, largely because css isn't a "complete" language.

I know some few who swear by them, but the majority of people I know who did html/css exclusively for years feel they can write by hand anything they would want from bootstrap in less time than they would waste in fighting things like selector specificity and other inflexible choices.

YMMV of course, and you can pry postcss + preset-env + mixins from my cold, dead hands.

It is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to customize them too much, and roll my own components for the rest. This largely sidesteps the issues I used to have of wrestling with UI frameworks. I hope that helps.

Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.

> Is this a common pattern in industry as well?

It is on the server-side (php, python). Sophisticated apps can easily outgrow a particular framework. Though, I think php frameworks are pretty mature these days and this is less of an issue there than it once was.

At the same time, you have to ask yourself if your customizations are so important that it's worth maintaining your own CSS. There are obvious trade-offs there. CSS files often incur irreversible complexity without someone dedicated to fight it. Forgoing a CSS framework completely has its own large costs like eternal vigilance, organization, and documenting some sort of strategy for other developers to follow (since they can't just read a framework's docs anymore).

It’s going to depend. If you’re going into the web front end field, you’ll be able to make that determination yourself.

For me, as an SRE with higher priorities, you can pry Bootstrap from my cold, lifeless fingers :) I have zero interest in keeping up with latest and greatest in CSS developments; like you said, Bootstrap gets you something up and running fast without much fuss. It’s good enough and it allows me to focus on other important areas.

The most common pattern in industry is to slather everything with libraries until you end up doing 10x the amount of work you needed to do.

An actual 'good' approach is to mostly utilise vanilla tooling like you suggest, but there are some exceptions, you can't be absolutist about it.

I think for a decently sized web application, React (and only React, not all the cruft people usually include with it) will save you a lot of effort, and not using it would be a mistake. You could go with something like Vue instead but React does a much better job at abstracting away the huge amount of utility it provides. It has a smaller API surface by an order of magnitude.

I think a good thought exercise is to think about what a 'perfect' implementation of the library you're thinking of using would look like for your exact use case, and compare it to using the actual library. Even if my use case doesn't include any performance requirements, I don't really think my implementation of a React-style solution would have less than 1k-2k LoC, and the implementation wouldn't be very simple. Contrast that to something like Redux which could be roughly implemented in ~20-100 LoC for most use cases and is conceptually very simple.

I'm quite surprised by the number of comments on Sass/CSS pre-processors being of little to no value while we have created a huge complicated Frankenstein mess with webpack/React and the rest.

I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then).

Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?

Web developers have a long history of doing it just because they can, not necessarily because they should.

Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today.

Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.

The fewer frameworks / compiles-to X languages you have to learn the better.

IMO, a little redundancy is better than a little complexity or a little dependency.

Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.

Variables alone are not a reason to use Sass anymore. There are CSS Custom Properties [1] now, which are even more powerful in that you can dynamically override them in specific sub-sections of the DOM. The only downside is that Internet Explorer 11 doesn't support them (if that's important for your target audience).

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

Using a find and replace instead of a variable holder is extremely bad practice. I should not have to copy/paste my site’s brand colors every time.

The original reason I switched was for nested structures so I could stop repeating myself. E.g.

div {

  &:hover {}
  .class ul {}

}

This made it much more pleasant to write in sass.

The other thing is mixins. If vanilla css doesn’t support this then it’s still a no-go.

Lastly I’m confused why sass of all things is an issue. It’s basically css, and very lightweight. You just add one step in your preferred build tool to transpile sass -> css. “vanilla is magically better” is not an argument.

I used to write only in Sass for these same reasons, but switched back to CSS.

CSS now has variables (if you really need them -- chances are you don't).

The redundancy of writing a selector multiple times is sightly annoying, but I don't think it rises to the level of value I need to include a new dependency in my app or build pipeline.

That still doesn't account for mixins, which turn out to be very handy. Some examples here.[0]

[0]: https://css-tricks.com/custom-user-mixins/

These are preferable because you can compose them as needed for elements, instead of having to make extra classes.

> CSS now has variables (if you really need them -- chances are you don't).

I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".

It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.

> When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".

Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.

Classes do suffice if you follow the convention of "small, atom-like css classes". I personally hate this style and prefer compositional css classes for a component or a structured object.

> Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.

Any self respecting programmer will find this "solution" abhorrent and inelegant.

Some would say adding a dependency that doesn't give you anything new you can't already easily do is abhorrent and inelegant.

There's a trend to throw a library at the problem, but that comes at a cost.

Well some of us think webpack/react and the rest are even worse and that a page-reload never killed anyone.

I don’t work in a tech-focused business, because I work in the public sector. That means our funding is fairly limited, even though 90% of our workforce spends 5-8 hours a day on some for of smart device or pc. Because we’re limited, however, we need to be careful about how we spend our resources, and that means we simply can’t keep up with the modern frontend environment.

If all you do is angular, then the transition from AngularJS to angular 2 might have been smooth, but it sure wasn’t for us, and neither would the big react-versions be.

We also can’t really take advantage of the package/library environment because we’re not as fault tolerant as others. We can’t have security issues, but we also can’t code-review 70 packages/libraries every week because there was an update.

As a result we’re back to using the old MVC frameworks that don’t change every day and have solid standard libraries. We did buy a frontend “platform” so we can have things like editable grids without constant page-reloads, but in general, JS is something we add to a specific component only if it’s absolutely necessary.

I am looking forward to when Flutter finally has the ability to build websites. Because then we’ll have both mobile platforms, web and desktop frontends covered in one tool. Which is frankly exactly what we need to be productive in 2019, that or we’d need to hire 2-3 people, and the latter is just not happening.

As a front-end developer it sounds just like the perfect job for me. I'm so tired of fighting the infrastructure and tooling instead of doing real work that I wish I could go back in time to work in simple MVC project. I don't really care if it's Rails, Django, PHP, .NET or Java. On my previous 4 jobs I wrote SPAs for products that weren't supposed to be a SPA. I wonder if there are still interesting products being built with these 'old' tech. Where I live certainly there isn't.

Yea, webpack sure is horrible.

Not like C/C++ programs, where we have a super simple setup of Make, config, and autoconf. Like checkout this easy-peasy Make file: https://github.com/apache/httpd/blob/trunk/Makefile.in . Even a child could understand it.

Or look at Java. Who has ever seen a complicated ant or pom file? No one ever. This Lucene ant file practically wrote itself: https://github.com/apache/lucene-solr/blob/master/lucene/bui...

I guess my snarky point is that build systems are complicated. It's like the Bjarne Stroustrup about programming languages. There are two kinds of build systems: the ones people complain about the ones no body uses. Robust build systems have to handle the nearly endless combinations of different requirements each app brings to the table...complexity is table stakes.

Modern web apps are built to be able to run on a myriad of different platforms, as they have to maintain compatibility between tons of version of several different browsers running on a slew of different device types running different operating systems. Did we think that was going to be easy?

People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.

And what are the alternatives? Yes, yes, yes, I know, your blog/website/thing you have is just plain ol' html and and you stick some javascript in a script tag or whatever. No need for any of these fancy build scripts, blah, blah. So what? That's like telling the people at lucene that all this arcane index stuff is overkill because you just search your hard drive using ripgrep.

You can't make a real app like Slack, Spotify, VS Code, or Google Docs without a serious build process. People are making photoshop, for the browser. They're not going to do it with ES3 they write directly into a script tag.

> People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.

The problem isn't that webpack is bad but too many projects use it where there's not need for it. Also for newcomers to the js world it looks terrifyingly complicated. Sure those bootcamp rookies eventually discover how terrible C++ buils are but who cares since this is more like comparing a spoon with a shovel.

> The problem isn't that webpack is bad but too many projects use it where there's not need for it.

Well, I feel that bit of nuance gets lost most of the time. It’s usually just simplified to “all these JS tools are a mess.”

It’s like if people all started complaining that rust is bad because they saw someone write a rust program when that person should have just written a bash script.

What I really love about sass is using https://include-media.com/

I hate writing media queries, but

  @include media("<desktop", ">tablet") {
  }

Takes most of the pain away.

Hello "human centered designer, specialising in interaction design, HTML & CSS"

Your font is too big.

Everything else v awkward as well

I recently built a new website from scratch after about three years working in other software areas. Found to my surprise that I came back with some very different opinions about how CSS should be structured than I had in my web dev days, and I didn't end up using SASS at all. Still think the code ended up cleaner and more modular than what I wrote before using SASS. The only feature I really missed was @extend, but making the code I would have put in the % selector an actual class and using that in addition to a specialization class in the HTML worked well enough.

The biggest thing Sass annoys me is in Node.js environment, I have to choose either node-sass which depends on native module which require extra compilation or matched pre-built binary. Or I have to choose ruby-sass which depends on a global installation of Ruby. Both of the options are brittle.

For SPA I found it's easier to use CSS-in-JS solution like styled-component or emotion. Or for Typescript I just use typestyle.

For non SPA I usually go vanilla CSS for simple stuff and stylus for complex stuff.

Worked a lot with CSS for 10+ years and SaaS' nesting is amazing. I still have no clue when to NOT nest, but oh well, it is so useful to componentize the stylesheets.

Nesting is okay for one-level.

However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere.

Instead, use modifier (in BEM) or create two buttons (.header-button and .footer-button) or create 2 utility class (.is-header-btn, .is-footer-btn) or just use TailwindCSS and you're good to go for all kinds of requirements, without ever resort to !important

> However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere.

That's true. On the other hand, who is still trying to figure those things out without using their browser's dev tools and source maps?

Using Sass also doesn't mean that you can't use two button classes or utility classes.

Yep, makes a lot of sense. I usually follow these guidelines but with larger "code as you go" projects, it gets a tad dirty.

Chrome Dev Tools help to find what's glitchy when styling misbehaves.

Interesting. CSS has certainly come a long way.

I'll still use Sass for the convenience of nested selectors, though.

Pedantic point. It’s ‘Sass’ and not ‘SASS’.

Sass certainly pushed things forward in CSS world. Without Sass and LESS, Stylus et al. I am quite certain we wouldn’t have CSS custom properties and colour functions. Great additions to the language.

That said, I left Sass specifically some years ago. https://benfrain.com/breaking-up-with-sass-postcss/

Tangentially related — in terms of dealing with CSS tooling/output for large projects with many devs I have found the PostCSS ecosystem indispensable.

I wrote this a few years back after setting things up with PostCSS at bet365.com this way: http://ecss.io/chapter9.html

The good thing about PostCSS is you can reduce the features as CSS becomes more capable and easily incorporate extra tooling like autoprefixer.

I need more coffee, I misread "Sass" as "SaaS" until several sentences in...

> I also unintentionally, (at least at first) removed all traces of Sass from my codebase.

Especially this part, still thinking that was "SaaS" :)

Reply on news.ycombinator.com