Hacker News Reader

Controversial opinion, but I myself use CSS preprocessors quite sparingly. I actually see nothing wrong with the CSS syntax. I like the fact that CSS is (almost) nothing but a bunch of named key-value pairs. The real issues have always been semantic, in the subtleties of the box model, which Flexbox is addressing somewhat, though more daring ideas like constraint-based styling are still niche.

Just look at the LESS example on the front page. The compiled output is simpler than the source you're writing. I find having some code duplication to be an acceptable trade-off for turning a basic declarative configuration language into a chimera DSL that must be incorporated into the build process.

The more a configuration language strays away from being declarative, the less desirable this becomes.

I think "some code duplication" massively understates it. Being able to use named variables for colors is on its own enough of a win to make up for whatever truth there is in the "harder to train developers" downside. The many other wins make it a no-brainer.

Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.

It's not the only downside to consider. http://adamsilver.io/articles/the-disadvantages-of-css-prepr...

There are a lot of advantages to them that need consideration too granted.

Certainly, everything has trade-offs, but CSS pre-processors are more heavily weighted toward the positive side of the trade-off calculation than pretty much anything else I can think of, especially in the "web technologies" space. I found lots of the arguments in the OP to ring true – things often feel far too fancy, and the more "boring" stuff has major appeal – but I found the arguments against CSS pre-processors there and in the article you linked very thin relative to my experience with them after years of using raw CSS.

I'm sort of coming around to this perspective as well. Ever since I read this article[0] on more of a APL/J/K style to CSS (the author's blog's CSS looks like this[2]), I've noodled with the idea of doing straight CSS again, in this pretty condensed format. It's kind of shocking at first, but does have its own charm.

[0] http://prog21.dadgum.com/200.html [1] http://prog21.dadgum.com/p21.css

Ironically in the context of the original article, it's precisely when you're trying to support IE 5+ or 6+ (or even more modest goals) that less/sass is really valuable, since you can generate chunks of CSS values with all the browser prefixes/hacky workarounds/etc, and still be able to think about things at a higher level.

I agree with your first point. Pre-processors, especially in the CSS realm, are so intuitive that there should be negligible training overhead. I believe they should be used past a certain threshold.

I disagree with your second point, however. Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized. However, there are plenty of applications that I use where I prefer to have a workflow built on discrete states (pages). They typically perform better in terms of rendering time and latency, both in terms of request and user action. (Just compare reddit's mobile beta to their previous mobile site. I still type in /.compact because I can't stand the new SPA.)

>>> Single page applications are good for pages with a high amount of short, repeated interactivity where concurrency and frequent status updates are prioritized

That's what I understand by webapp. Web sites (such as reddit) should stay server based.

> > > There's a time and place for SPAs, you can't just dismiss it entirely. Every web app today should be an SPA.

I feel like this is a joke or amusingly unintentional.

Honest question, what's wrong with SPA?

The author write and linked to an article on the downsides. While I haven't read it, I do rage every time I click on a link to a Blogger.com-hosted article and watch some fucking Blogger logo animating as they load a web app to show me some static text. There’s no need for anything to load before showing me the blog page. The experience has been degraded and made more fragile, not enhanced.

I've read many articles about SPA issues. I don't think any of them can't be overcomed.

But when I say webapp I don't mean blogs or regular mostly static websites. I mean Web applications.

Similar to how I hate all hamburgers because of those damn dry McDonald's buns.

Nothing's really wrong with SPAs (they have benefits and drawbacks).

What's wrong is making a blanket statement that "every web app" should be one. Also you're trying to draw a fine distinction between web apps and websites, which could be another discussion altogether, probably with no big agreement on where to place the line.

Sorry, didn't mean to sound like I was making a blanket statement. I agree there's a fine line between web app and website. No-one should take the decision of using an SPA lightly.

Given that the vast majority of end users are not techie - what value does SPA add to an end user of a web application?

Interactivity mostly. Imagine if Google Maps reloaded every time you zoom in or pick a location.

Google Maps is famous as a pioneering use of AJAX, not as an SPA. Whether it is or is not an SPA at present is largely immaterial. There are many ways to create interactive experiences without full-page reloads, and going full SPA is just one route.

Sorry, I'm a bit confused about the difference between an Ajax powered page vs an SPA

AJAX and the ability to manipulate the DOM has been around for about a decade or so, AJAX came out of Microsoft I believe.

Putting bits of AJAX into a web app doesn't make it SPA. Lets say you have a CRUD web application that is tax forms which end up being 5-10 "pages" printed. Then as a SPA you would have to load all the code to generate the 5-10 pages of forms, validation, logic, etc. onto a Single Page. This single page would be where everything is done, the URL would not change and the end user would have a seamless experience.

If the goal is interactivity and seamless operation to the end user, attempting to mimic a desktop app, there are multiple paths to achieving that goal. Limiting the design to a single page seems sort of contrived and a "do it because I can" type of approach, absent of user requirements - in my opinion.

>>> This single page would be where everything is done, the URL would not change

There's HTML5 history API, lazy loading... Seriously, you describe SPAs in very simplistic terms that are just not true. Do you have any experience building them?

Google Maps is technically an "Ajax powered web app", but it's technically an SPA too as you never encounter a full page refresh.

If people disable JS or if it fails for whatever reason, you'll be left with an unusable site. If fonts don't load or if css doesn't load, at least you still have html and you could read what's on the screen. With JS you won't even be able to navigate to pages since it all gets handled with js.

That and it often has more to load than your traditional html/css page, which means a less pleasant experience on slower connections (mobile).

Not true if you use a decent framework.

If your framework just saves up json like most SPA's, your pretty much SOL unless you do non-js fallbacks, but that's boring and tedious ;)

Yes, hugely ironic. “Listen, these things are never black-and-white. [pause in which audience expects a call for careful consideration, case-by-case.] They are always white.”

people act like once you get the team on board it will all start rolling, EXCEPT that there are a lot of projects where people come and go, people are temp, permanent and everything in between, changing constantly.

Of course there's documenting right? Except you document and do this fantastic job training but when it's all set and done, technology has moved on when the project wraps and there's already something better that can't coexist with the method you used.

Preprocessors also have disadvantages, not just training. Every time you abstract something, then abstract it again you are risking that what comes out could be problematic and harder to fix.

think about this. in the end, the browser is displaying based on the final CSS. You inspect the final css. If you're trying to fix something, you have to discover it, then work backwards to it's source. Inspect tools show you what's there and what you have to edit. But it takes yet another set of steps and complexity to work backwards to your css before it was processed.

make sense? So tech moves on and new complexity and longer problem solving procedures are introduced. Yay. No wonder there's an attraction to being boring.

To rework a quote from bruce lee for this. The guy who practices one kick a thousand times is much more formidable than the guy who practices a thousand different kicks one time.

You might be interested to learn of source maps.

This should phrased about how much you lean on preprocessors. Sass is more more intelligible than regular CSS in many circumstances unless you're trying write everything as programmatically as possible. Its easily to write a For loop that spits out a grid but may make look like greek to a junior dev.

CSS preprocessors are unique, with LESS and Sass, you can write straight CSS and use its wonderful concatenation through imports, or just its nesting or perhaps simple variables for colors. There's so much benefit that I can't imagine not using them.

With regard to the preprocessor question, I didn't read that as condemning preprocessors. Rather, it was in answering the question. Let's use LESS as an example

> Will it be harder to onboard developers?

No. LESS is similar enough and we've automated the build process, so it will not be harder. People that can write CSS can learn LESS easily.

> Will debugging code be more difficult?

No. Again, the similarities are already well established, and most debugging will happen within the browser. The tooling already exists to make this easy.

To me, harder doesn't mean you won't have to learn something new, but it's actually more difficult. And that entirely depends on how you have things setup and what tooling you have. This does mean that if I invite LESC and want to use that instead of LESS, it will be harder to use precisely because the tooling isn't present.

Sounds like you are desperately reading something into the original article which just isn't there. The author is clearly saying to skip the preprocessors, and this is a really backwards and ignorant position to take in 2015. CSS has a some major weaknesses and Sass/LESS do a great job patching those holes.

I am saying,consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision.

Sounds like you are desperately reading something into the original article which just isn't there. The author is clearing saying consider all the disadvantages too. If you still think it's beneficial after that, at least it's a conscious decision. Your comment has a some major weaknesses and reading does a great job patching those holes.

> Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any [sic] of these questions is yes then the BFED will say no to preprocessors.

— TFA

Read literally, the paragraph says “If there are any downsides, do not use preprocessors.” A more balanced approach of weighing upsides and downsides is not supported by the original text.

If the author wanted to say something different, he can and should have done so. I encourage him to change his call to action from “say no to preprocessors” to “be conscious of decisions.” It’s much more defensible and realistic!