Hacker News Reader

None of those features matter if you're of the opinion that conditionals, loops, and functions don't belong in the styling system.

I don't think that these features are really in the styling system - Sass is essentially a tool that makes it easier to generate CSS, rather than being a replacement for CSS. And the output of that is a static, declarative stylesheet with no logic. I don't consider that any different from (say) a set of macros.

I won't be spoiled by all those fancy features that will probably never get implemented in vanilla CSS4/5.

I absolutely love Sass, especially when combined with Compass. I agree that those features will never be implemented in CSS, and they are IMO not appropriate features for a declarative styling language. But it's not like Sass is going away any time soon, and it has the massive benefit of being an effortless transition to CSS if you want to do that in the future. But in the meantime, I see absolutely no legitimate reason to avoid using it.

I think this is a bit short-sighted.

It's not about Turing completeness. It's mostly about DRY and flexibility.

For instance, imagine using theme prefixes or conditionals.

For-loops are fantastic for grid systems.

The point of this article isn't "should you use a pre-processor" - it's pointing to the fact that if you use one, SASS has more natural structures for common tasks like for-loops or conditionals, both of which are indeed useful.

It's not shortsighted at all. CSS is declarative because if its programmatic, you might as well generate it with a real language.

The same could probably be said of most of the HTML generators out there. HAML, in particular, has a lot of similarities.

I agree that programmatic things should be done with programming. I also think that for those who are coming from CSS, the barriers are lower with something that has the shape of CSS.

And, the other part of this argument for pre-processors is that they "work." If I were to approach most junior front-end devs with a given programming language versus SASS to generate their CSS, most of them would pick SASS simply because of syntactic familiarity. Not a particularly compelling reason methodologically speaking, but the natural shift does make it a reasonably easy transition from purely declarative to pseudo-dynamic.

The purist in me agrees, but the practical implementation says these things are valuable.

It's a superset of CSS language that provides an additional DSL that extends it in a number of ways that provide significant productivity and design benefits.

Exactly why would a "real" language make more sense than that?

That might be the opposite of what you want if there's any chance you'll be working with a heterogenous web stack.

Define your styling framework in scss, use it from multiple backends.

A common case is to share between a static site generator for a public site, and an app framework for the app, which may well be written in different languages.

> None of those features matter if you're of the opinion that conditionals, loops, and functions don't belong in the styling system.

I think the terminology doesn't convey the right idea. A SASS function is more akin to a macro that saves you a lot of typing and gives flexibility in writing CSS. At the end the result is plain styling instructions, no more no less, and thus it has no functional similarity with a js function parsed, loaded and executed at runtime.

And yes, preprocessing doesn't belong to the styling system, and it doesn't need to, as you use it a level above (it would be meta-styling I guess).

>Do we really need to turn the styling system into yet another Turing-complete scripting language?

There's a really big difference between a Turing complete preprocessor and a Turing complete styling system.

There are clear advantages to having the client receive styling information in a non-Turing complete format, the major ones being performance and avoiding non-halting programs. A Turing complete preprocessed language does not remove those advantages, because preprocessing happens only once.

In fact, I would argue that it increases those advantages. As you mentioned, we already have JavaScript, which can be (and often is) used to manipulate styles. If you want to avoid a Turing complete styling system, then you want a Turing complete preprocessor. Better to have the arbitrarily complex program running once on the server side via SASS, than to have it running in the browser on every page load, via JavaScript.

Hear hear.

I was reading this thinking, "Why would I need /that much/ complexity in the stylesheet? I get variables and some other niceties... perhaps I'm not thinking complex enough with HTML5 video games and whatnot.