2 comments

  • Matt SistoMatt Sisto, over 2 years ago (edited over 2 years ago )

    This is awesome. Haven't used it but it seems promising. If not, kuddos to this guy anyway for trying to fix our hard problems. PostCSS sure does seem to be inspiring some amazing work.

    Love this:

    We no longer need to add lengthy prefixes to all of our selectors to simulate scoping. More components could define their own foo and bar identifiers which — unlike the traditional global selector model—wouldn’t produce any naming collisions.

    People joke that naming things is the hardest problem in computer science, but seriously how much time have we spent collectively trying to think of what to name a "header"?

    We write things like ".navbar-header" because the styles live in the global scope and there is no real mainstream technique for achieving total isolation, while keeping your code DRY, that doesn't have some serious negative consequences.

    Deep nesting in Sass bloats your stylesheet and puts you in specificity hell. Inline styles (which are, ironically, the key to this concept) are basically unmaintainable. BEM is hugely helpful — I use it on everything — but is a methodology, not actual protection. Plus, BEM is ugly; not a non-starter but definitely annoying.

    Frankly, I'm sick of spending an inordinate amount of time and mental energy compensating for the shortcomings of CSS.

    It's frustrating to know that new specs like WebComponents will transform how we work in a similar way, but to not be able to go "all-in" because WebComponents itself is not quite ready for prime time.

    I'm drawn to this in the same way that I was drawn to Sass initially: Nesting allowed for me to structure my CSS in a way that echo'd my HTML's structure. It abstracted away the problem of naming things. I know that is a terrible idea now, but at the time it was truly liberating and I find it difficult to have only gotten a taste of what that felt like.

    To me, this is an incredibly intriguing option that could be a perfect stop gap solution, and one that gets us thinking in legitimate object-oriented terms.

    5 points
  • Mike PropstMike Propst, over 2 years ago

    Reminds me a bit of the presentation by a Facebook engineer on why they're using inline styles on all React components. The path he shows for how they got there is a mess of overengineering that could've been solved with a preprocessor and even a basic understanding of CSS architecture. The end result is a mess that's the exact opposite of DRY.

    That said, our team is doing something similar to this article (packaging the individual style assets with React components using Webpack and loading them as necessary) and it seems to be working thus far. My problem is the way people recently seem to be talking about core functionality of CSS — the ability to style things site/app-wide — as a "necessary evil." I see a fundamental misunderstanding of not just how it works, but how it's intended to work in a lot of these articles.

    I also didn't like the UNTIL NOW "here's your savior" tone but that's pretty standard for DN/Product Hunt/etc.

    0 points