Blaze CSS – Open Source Modular CSS Framework | Hacker News Reader

Blaze CSS – Open Source Modular CSS Framework

blazecss.com

110 pointsrtcoms56 comments

"Un-opinionated" right next to "BEM". It's like saying WinAPI and COM is un-opinionated.

My thoughts exactly. Also labeling Semantic, Bootstrap etc. as monoliths, yet they both offer custom modular builds.

It's unopinionated in the sense that it's opt-in only. But they already have opt-in as the first selling point. Any css framework that gives you component classes (how things look) is opinionated by definition.

It's un-opinionated as in styling is drawn back but not to the point of it being ugly. Look at a Blaze site and it doesn't look like a Blaze site. Everyone can tell when a site has been Bootstrapped. It's aiming for an un-opinionated solution rather than source code

Really nice. The only thing that would prevent me to give it a real go to is that it is a one man project not backed by any company...

Isn't one of the main tenants of OSS that it can organically grow beyond a single person without the need for company backing?

> Really nice. The only thing that would prevent me to give it a real go to is that it is a one man project not backed by any company...

I understand this position for large, dense frameworks (i.e. Rails, Zend, Spring) that you are basing your entire codebase on. Heck, I can even see an argument with Javascript (largely due to Node, React, etc. having a substantial impact you design around).

This is CSS. Pretty much any front end developer can maintain a CSS framework that was dropped by its creator if push came to shove.

Wasn't Linux originally a one man job as well?

Would you use a 1-man-developed OS on your servers?

Linux is no-longer a 1-man show.

Well... Angular Material is a multi-person project that is (seemingly) backed by Google, but they are abandoning 1.x release (1.0 was just released last October) to make the 2.x release Angular 2.x-only even though Angular 2.x isn't really ready for prime time (at least in my opinion). They also made promises last fall about how it would be "supported for a long time to come."

So, let's say that more people and a company don't necessarily equate to better, longer-lasting support.

One counter example does not detract from the point. A company-backed project is far more likely to last a long time. I could point you to thousands of examples of abandoned 1-man projects.

I'm just saying that it's never a sure thing, not that the opposite is always true.

Well, that's sort of how d3.js grew.

Vue is an example of a one-man project lots of people build on; it can be done and be done well :)

From my experience this is a non-issue in the OSS environment, you got to pick your frameworks based on other criteria; popularity, fit for purpose, community engagement, learning curve to maintain yourself etc. All of which has nothing to do with company or individual ownership. Blaze benefits from an MIT licence so it's totally accessible

Why does that matter? There have been major projects backed by a company that have gone away. There have been major projects backed by one person that have been around for years.

It's all about probability.

The probability of what? You'll always be able to use this, as it's open source. Even if it somehow wasn't, it's CSS, so you'd still be able to tweak it however you want. I don't understand what the downside is here.

Valid concern. I'll do my bit to reverse the downvotes.

Is being a one-person gig really a valid concern for open-source? What's the worst case? That the bus factor kicks in and someone has to fork it to continue the work? That's not such a terrible outcome. Certainly better than, say, when Google decides to wind-down a closed-source project.

Yes. There are thousands of 1-man projects that have been abandoned. People here quoting the examples where something starts as a 1-man project and is now super popular just illustrates the wisdom in waiting to see which few of the many actually catch on.

What's the benefit? The benefit is that you aren't left as the 1-man crew maintaining the project after the other 1-man gives up.

Would I use a 1-man backed CSS framework? Probably. But that doesn't mean melicerte is wrong.

This looks really good. The grid is much more customisable than bootstrap/foundation.

Thanks! Worked hard on the grid!

Is there a reason beyond the marginal performance difference, why there are no global modifiers in BEM?

I find the c-button c-button--primary a bit annoying. Why not just c-button primary and define them like this?

    .c-button.primary {
      …
    }

Or namespace it:

    .c-button.m-primary {
      …
    }

It's not so much about performance, it's about specificity. To override anything in `.c-button.primary` you'd need something to have equal or greater specificity (meaning you couldn't do `.c-button--large`).

Obviously this is a fairly basic example, but with more chaining comes more levels of specificity which makes for increasingly difficult changes and worse productivity.

I've done a fair amount of CSS in my time and I have felt the pain, I understand why BEM wants to keep specificity at 1.

One thing bothers me though. Isn't this very WET? You have to repeat the `.primary` rules in every `--primary` thing?

I'm still torn apart about `.button.primary` and `.button--primary`. Also semantic classes vs style bound classes. I'm not completely convinced by any methology.

I don't get your example.

What's the difference between

    .c-button.primary { … }
    .c-button.large { … }

and

    .c-button--primary { … }
    .c-button--large { … }
?

.c-button--primary has lower specificity that .c-button.primary

But .c-button.large has the same specificity as .c-button.primary.

Indeed, but with BEM, you keep a specificity of 1, which means you can override styles simply by adding a class and ensuring that it is further down in the style sheet than its other base classes.

Like mentioned above, this keeps things simple and prevents the snowball effect of people continually adding classes or selectors to override styles.

Single Reaponsibility principal. Create a class called .button. The responsibility of that class is to define what a button looks like. Then create a class called .button--primary whose sole responsibility is to define what a primary button looks like. If you create a class called .primary it has multiple responsibilities spread over the solution making it harder to maintain and improve upon

BEM basically gets rid of combination of classes because some people feel as though it is very difficult to locate every location of a class in css. So if you typically only define styles for any element once(or once for every font, color etc section) you are less likely to have unexpected changes. A lot of times it happens in reverse.

  <section class="frogs">
    <h1 class="headline frogs__headline">Frogs</h1>
  </section>

  <section class="frogs">
    <h1 class="headline">Frogs</h1>
  </section>

So in the second one some sadness happening possibilities of a developer being a jerk:

1. Removes the "frogs" class from section. Now the baseline headline applies to the h1

2. Buries this joy somewhere

  .frogs h1 { sadness: here; }

3. Wraps the h1 in a div or something clever for some effect or whatever

  <section class="frogs">
    <div class="sweet-slider-plugin">
      <h1 class="headline">Frogs</h1>
      ...
    </div>
  </section>

and someone wrote the rule as

  .frogs > .headline

because further down in the section someone else used the .headline class nested in a "frog of the day" sub section.

I'm definitely not trying to say BEM is what you have to use. Or if it is good or bad. Just trying to explain that there is an actual point to it.

That's called the BEM naming convention. BEM stands for block, element, modifier. You can read about the reasoning for it in places like this one: http://csswizardry.com/2013/01/mindbemding-getting-your-head...

I know BEM and was asking for reasons why there are no global modifiers for things that make sense on every block or element (e.g.: importance, size, state) other than "that's not BEM".

Yes, frontend layout designers reinvented Hungarian notation. It'll take another 10 years to realize it's not a very good idea.

If I am not mistaken, the Hungarian notation part in Blaze (o-…, c-…, …) is not needed for BEM. Just a prefix to distinguish different kinds of blocks.

I think you're missing the whole point of BEM. Your suggestion is something I would avoid at all cost.

Here's a good article explaining the idea:

http://csswizardry.com/2013/01/mindbemding-getting-your-head...

I think you would avoid defining .primary I don't see a reason, why you would not define .block__element.primary.

> I think you would avoid defining .primary

How would you enforce that when working in a big project with many contributors? I don't want to risk breaking my component if someone all of a sudden declares a global .primary class. When using --primary I know that won't happen since it's completely bound to my component.

> How would you enforce that when working in a big project with many contributors?

So what you're saying is that BEM is the Java of CSS? Because that explains a lot.

Small thing I noticed: on http://blazecss.com/components/buttons/, the 'link' button made from a normal <a> tag is slightly larger (Chrome 51).

Could raise an issue in the repo if it's still a problem?

Quite nice.maybe will be used it for future replacing twitter bootstrap.

Any feedback you can give would be appreciated ;)

I love the opt-in part. I really like building stuff in Bootstrap but I loathe the fact that it changes a lot of stuff implicitly, making me feel I lose control.

Correct me if I'm wrong or misunderstanding, but apart from basic typography (relative sizes and spacing of headings and body text), bootstrap has been opt-in since bootstrap 3.

Everything else requires adding classnames or using mixins before bootstrap starts to take effect.

If you don't want the typography stuff you can uncheck it on the customize page. (Or if you're using Less/Sass delete the typography import e.g. delete `@import bootstrap/typography` . from `_bootstrap.scss`).

I think that is correct. When I was using bootstrap 2, I downloaded a custom version that didn't include styles. It was annoying because it also changed basic styles. Bootstrap 3 leaves things alone.

for those unfamiliar with the customize page mentioned. http://getbootstrap.com/customize/

I do appreciate the additive approach blaze is taking. Add what you want.

Blaze doesn't mention Bootstrap specifically regards opt in. But Bootstrap does apply CSS to some elements without permission. Foundation even more so. SemanticUI too. Blaze is different than all of these in that it gives the power back to you!

Only what I addressed. Typography, which you can disable or override easily.

Let's be clear, Bootstrap is the most popular CSS framework in the world, whose Github issue threads have been pored over many times more than Blaze's are likely to be for a very long time, and Bootstrap 3 at least never took any power away.

There are some really cool looking elements to Blaze and I'm very interested in using it for some upcoming projects, but to infer that you should ditch Bootstrap for it, on the basis of opt-in vs opt-out is very misleading.

Despite "un-opinionated" being one of their main selling points, using BEM is SUPER opinionated.

Mentioned above: It's un-opinionated as in styling is drawn back but not to the point of it being ugly. Look at a Blaze site and it doesn't look like a Blaze site. Everyone can tell when a site has been Bootstrapped. It's aiming for an un-opinionated solution rather than source code

Your dashboard example is freaking out a little.

Here is a short clip of it: https://www.freeih.com/tAgTSr

os/browser? could not replicate here on mac/chrome

Typo on the front page, 2nd info box - "Mirco-frameworks tend to sacrifice a lot of usefulness for the file size, leaving the developer wanting more".

Fixed ;)

Resizing feels very snappy!

Reply on news.ycombinator.com