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.
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.
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.
> 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.
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.
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
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.
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.
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.
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
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 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".
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.
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.
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.
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
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
57 comments
[ 3.6 ms ] story [ 38.6 ms ] threadWhat'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.
Linux is no-longer a 1-man show.
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.
So, let's say that more people and a company don't necessarily equate to better, longer-lasting support.
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`).
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.
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.
I find the c-button c-button--primary a bit annoying. Why not just c-button primary and define them like this?
Or namespace it: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.
What's the difference between
andLike mentioned above, this keeps things simple and prevents the snowball effect of people continually adding classes or selectors to override styles.
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.
Here's a good article explaining the idea:
http://csswizardry.com/2013/01/mindbemding-getting-your-head...
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.
So what you're saying is that BEM is the Java of CSS? Because that explains a lot.
1. Removes the "frogs" class from section. Now the baseline headline applies to the h1
2. Buries this joy somewhere
3. Wraps the h1 in a div or something clever for some effect or whatever and someone wrote the rule as 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.
Here is a short clip of it: https://www.freeih.com/tAgTSr