Comment by Emil Moe on "CSS methodology: To BEM or not?" | Hashnode

Popular posts

Emil Moe

Senior Data Engineer

Oct 6, 2018

I thought about using BEM and tried to use it, but I have quietly gone away from it again. As you point out the naming conventions are often very and it leads to a few overhead problems:

Hard to remember the correct path name and no IDEs will help you
If the structure changes you might have to refactor a lot of CSS
Longer class names means more bytes, not much, but it's a margin

Since I'm uing SCSS it makes more sense to try to adapt a namespace OOP pattern to my CSS. Simply if I have a component testimonials that would be:

.testimonials {
  > .testimonial {
    > .title {
      // CSS
    }
  }
}

If you are consistent doing this and not making an independent .title then this approach works very well in my opinion.

If you want to have a generic class, you can always use BEM here:

.utilitiy__ {
    &title {
      // CSS
    }
}

But you could also simply call it .title as it would still not be inherited from a .testimonial

Hard to remember the correct path name and no IDEs will help you

That's the biggest pain point, imho. Different people define different things as blocks and there is no adequate tooling to resolve the names. It's not that it wouldn't be possible, it's just that no one bothered to write tooling. Maybe partially because people fear BEM or think that it's tedious.

If the structure changes you might have to refactor a lot of CSS

BEM is not about your HTML structure, but about what the element does. So, if the element is a div inside a table, which contains the login info, and you want to modernize your page and move the whole login section to its own page, the CSS naming will not change, because it's still the login block, with a login-username-input and a login-userpassword-input.

<!-- old prehistoric HTML -->
<table>
  <tr><td>
    <div class="login">
      <input name="user" class="login__user">
      <input name="password" type="password" class="login__password">
    </div>
  </td></tr>
</table>

will later on still be

<div class="content">
  <div class="login">
    <input name="user" class="login__user">
    <input name="password" type="password" class="login__password">
  </div>
</div>

and if it isn't, you probably created something new anyway.

Longer class names means more bytes, not much, but it's a margin

You DO know that your SCSS will be compiled and then all classes will be put in one single hierarchy, which means, they all have to be prefixed, resulting in a lot more bytes than BEM?

.testimonials {
  > .testimonial {
    > .title {
      /* CSS */
    }
    > .description {
      /* more CSS */
    }
  }
}

will become

.testimonials > .testimonial > .title{/* CSS */}.testimonials > .testimonial > .description{/* more CSS */}

while BEM is already CSS and always stays the same

.testimonial__title{/* CSS */}.testimonial__description{/* more CSS */}

I don't think I need to count bytes for this final result...

Jason Knight

The less code you use, the less there is to break

Oct 10, 2018

Dan W.

but the problem is that the vast majority of the clients who want to publish a website don't give a rats tail about how you code your site.

Right up until they land in COURT with FINES for accessibility failings as a direct result. Right up until the increased bandwidth costs more to host and keeps bringing servers to their knees. Right up until such failings result in large swaths of users being told to sod off...

They just care that it works for visitors

You mean like visitors using screen readers and braille readers for whom the semantics is all they get? Visitors who are more likely to find the page in the first place if it ranks better and more relevantly in search thanks to said semantics? Non-visual visitors who will have an easier time navigating the page if you bother using H1..H6 and HR properly? (which you use those properly 90%+ of what that "aria role" BS does is a pointless redundancy and code bloat!)

And, not to mention BEM is FAR from being "poorly coded." And you are worried about adding a few extra characters in your HTML files because of BEM??

Thing is it's not "a few more characters" -- more often than not it's DOUBLE OR MORE the code needed to do the flipping job, introducing issues like specificity hell (a laugh since that's what it's supposed to be there to prevent), and tends to encourage (though it's not required, you CAN do it properly) the use of non-semantic markup telling large swaths of users to go screw themselves.

Remember, it's 2018. We have the brute force of the broadband Internet.

... and there's that same lame excuse I've been hearing for two decades, that still means Jack to most of the planet with the overall market of 256kbps or faster internet still being below 60%... with places like Chile, Mexico, Greece, and Portugul being below 25%, and even Utah, Colorado, the Dakota's, and Coos Count NH just 40 miles north of me hovering in the single digits.

That being before we talk bandwidth caps since not everyone has the luxury of unlimited throughput, charges for bandwidth overages, bandwidth throttling under high use, etc, etc... You know, that whole thing Net Neutrality is supposed to be fighting? You HAVE at least HEARD of that, right? Just ask our friends in Canada and Australia about bandwidth caps, slowdowns, and overage charges.

So sure, you and I might have big fat broadband pipes; well lah-dee-huffing-dah for US! That doesn't mean that more than half the people online aren't under some form of restricted / less capable connection. For a good chunk of the world you ask them how broadband penetration is going in their area, they'll ask "Is it in yet?"

... and that's before we talk about choked out shared connections. Well great you've got 60mbps, means dick if wifey is watching Netflix, pookie is torren... uhm... creatively acquiring media, leaving you with a narrow slice of what's available. Or all the users sitting at internet cafe's or at business' worldwide where you have 20 or more users sharing a single 15mbps connect.

Even without all of those concerns, so what if the end user has broadband? YOUR pipe out of the server is only so wide, cutting your bandwidth use in half -- hell even just a 30% reduction -- can be the difference between $10/mo in a cheap VPS and a $500/mo cloud. You start serving thousands of requests a second the typical 1gbps server pipe starts looking like a soda straw!

More so since the more markup you have the more time the server has to waste pasting crap together! The more of it you can move out of the markup the better.

Quite frankly, fussy coders always do an unnecessary favor by arguing against innovations

What innovations? Dragging things back to the worst of HTML 3.2 / 4 Tranny practices with broken inaccessible train-wreck laundry lists of how not to build websites tools like Frontpage and Nyetscape Composer vomited up?

Unnecessarily harder, the better!!

... and how is writing half the markup and pretty much the same amount of CSS "Unnecessarily harder", particularly when it means doing the job PROPERLY so that the end result is useful to EVERYONE, not just a select group privileged with perfect vision on desktop resolution screens?

That's the claim I keep hearing about all this crap -- be it front end frameworks, BEM, OOCSS, LESS/SASS/SCSS -- these wild unfounded claims of being "simpler" or "easier" or "makes you more productive" when in my experience they do THE EXACT OPPOSITE!!!

Though I'm right there with you on vi/vim, we can do better... but I don't go as far as IDE's since they are filled with garbage that just gets in my damned way.

Bottom line, as I've said many, MANY times, maybe, just MAYBE if people would stop wasting 64 to 256k of markup on doing 16-24k's job, half a megabytes of CSS spanning a half dozen files to do 32-48k in one file's job, and megabytes of scripting spanning dozens of files on pages that don't even warrant the presence of JavaScript, MAYBE they wouldn't be so easily suckered in by any of this rubbish. Much less make endless nonsensical claims of 'benefits' that are the exact opposite of what any of this garbage actually does!

Dan W.

Oct 10, 2018

Jason Knight

Server down?? Adding even 100 classes each using 30 ASCII characters will NOT bring down a server. Nonsense!

Screen readers: Not everyone needs to address that, and clients are on a tight budget most of the time. Are you honestly suggesting that an online store selling glasses should care about this so visually impaired people could use their screen reader to use the site? The site is irrelevant to them, so why should the store owner spend any money on it? Besides, screen readers should be able to figure it out for them, not the other way around. There are already billions of web pages without aria role tags even if you decide to add them to your site. It's the reality, and machines should do all the dirty work for us, not the other way around!

"DOUBLE OR MORE the code needed to do the flipping job??" Simply not true. It would be "class="menu this and that"" vs. "class="menu__this" at the most.

Bandwidth and innovation: Pushing to the higher end push the rest of the world to upgrade and make progress. That's how tech has always revolutionized everything. Push smartphones with more features and more people will get out of old hardware misery. ISPs would not have any incentives to upgrade slow services if we didn't have more advanced modern websites. So, sure, "well lah-dee-huffing-dah for the US!" but the rest of the world will follow our examples, and everyone will win in the end. Now THAT is progress.

BEM is innovative because it eliminates ever thinking about specificity in the first place and make everything modular. No more "AW MAN, why is this new CSS class not working????" head-scratching irritations every time you change ul-li based nav to nav-a based structure. Swap the tags and voila! Everything still works! That saves time, sanity and mental energy.

IDE: I rely on WebStorm's autocomplete and various time-saving features. In my observations, fussy developers arguing for tradition and not for innovation and changes are the one unwilling to learn how to use IDE's features effectively. They are so stuck on doing things the same way. That's why some of them say vim is better than WebStorm, etc. modern IDEs. Nonsense.

Ok, let's say you are right about throwing out BEM. It will go like this:

Me "Sorry, I won't use BEM because it bloats your site." Client "Does it cost anything extra?" Me "Yes, $2,000 more because I have to spend more time wrestling with CSS specificity." Client "Forget it. I'll hire someone else who builds the same kind of site for less." Me "You need to spend $4,000 to add accessibility features." Client "We don't need it because we don't have customers who need such thing." Me "Yes, but, but, it is..." Client "Never mind. I'll just build our site with WordPress and ThemeForest theme."

That's even worse than using BEM.

Jason Knight

The less code you use, the less there is to break

Oct 10, 2018

Dan W.

Are you honestly suggesting that an online store selling glasses should care about this so visually impaired people could use their screen reader to use the site? The site is irrelevant to them, so why should the store owner spend any money on it?

Do you even realize how dumb that example is? You say it yourself "Visually impaired"! THE target audience of screen readers since partially visioned people may actually need assistance using websites, having them read aloud to them being a very nice convenience. The partially sighted using screen readers may -- I don't know -- ACTUALLY NEED accessibility when shopping for their reading glasses?!? Whoddathunkit?!?

Are you honestly suggesting that an online store selling glasses tell the visually impaired -- which includes the partially sighted -- to bugger off?

Simply not true. It would be "class="menu this and that"" vs. "class="menu__this" at the most.

No, completely true because in the majority of cases YOU PROBABLY DON'T EVEN NEED THE FLIPPING CLASS!!! So at most it would be class="menu this and that" vs. ... NOTHING

Hence why mouth-breathingly idiotic dumbass dipshit code like this:

<div class="top menu">
    <h1 class="menu__heading">Site Title</h1>
    <input type="checkbox" id="mainMenuShowHide" class="menu__checkbox">
    <label for="mainMenuShowHide" class="menu__label"></label>
    <ul class="menu__row">
        <li class="menu__list">
            <a href="/about" class="menu__link">About</a>
        </li>
        <li class="menu__list">
            <a href="/blog" class="menu__link">Blog</a>
        </li>
        <li class="menu__list">
            <a href="/contact" class="menu__link">Contact</a>
        </li>
    </ul>
</div>

Has ZERO legitimate excuse for any competent developer to be using more than this:

<div id="top">
    <h1>Site Title</h1>
    <input type="checkbox" id="mainMenuShowHide">
    <label for="mainMenuShowHide"></label>
    <ul>
        <li><a href="/about">About</a></li>
        <li><a href="/blog">Blog</a></li>
        <li><a href="/contact">Contact</a></li>
    </ul>
</div>

515 bytes the BEM way vs. 266 bytes the non-BEM. Not quite half, but over an entire page it is quite often anywhere from half to a tenth the code by the time you're through. MORE than that if you slop scripting only elements in the markup, piss away any semblance of semantics, and slop classes at everything willy-nilly presentational style. BEM is a contributor to this DUMBASS notion of blindly throwing classes at everything for no good reason apart from -- here come those words again -- ignorance, incompetence, and ineptitude.

It's a bit like Carlin's joke about abortion; not every ejaculation deserves a name -- so not every element needs a class! Use selectors to inherit off the bloody parent!

BEM is innovative because it eliminates ever thinking about specificity in the first place and make everything modular.

See, to me it does the exact opposite since it ties the markup too closely to the CSS, so if you move semantic blocks between sections they do not automatically pick up the matching style of the subsection without changing all their classes!

... and really if you land in specificity hell in a manner that "throwing endless pointless classes at everything" fixes for you, there is something criminally wrong with your HTML, CSS, or both.

and in some cases I mean criminally wrong in the literal sense; such as websites for banking, insurance, medical, government agencies, etc.

irritations every time you change ul-li based nav to nav-a based structure.

Gehugafugah?!? What the blazes is a "nav-a" structure? Do you mean the dumbass ignorant practice of omitting ul/li in a menu because you have a NAV tag, which completely ignores and misinterprets the purpose and semantic meaning of the (ultimately redundant) NAV tag?!?

You do know that:

<nav>
    <a href="/about">About</a>
    <a href="/blog">Blog</a>
    <a href="/contact">Contact</a>
</nav>

Is basically a run-on sentence reading "About blog contact" since there's no block-level semantics, no grammatical dividers, and NAV just means "you can skip this section to get straight to the content", right? That's why the specification actually still says a menu -- even inside a NAV tag -- should STILL semantically be coded as a list?

Not that I know anything about writing run-on sentences.

If that is in fact what you meant by that, you're simply proving my point that the people who defend rubbish like BEM do NOT know enough about HTML to be arguing the point.

Of course if you were just writing semantic markup in the first place, you wouldn't be changing from UL/LI to anything, since that's still the proper semantics and has been since MENU was deprecated... and no NAV didn't change that. NOR would you need to change much of anything markup-wise since the markup would/should remain relatively static -- at least for the semantic and behavioral tags -- regardlessof what you're doing for layout. Same goes for your document order and logical document structure. (more so now that CSS grid layout and flex let you play with the display orders and placements)

Since again, HTML is for saying what things ARE, and NOT what you want them to look like!

I rely on WebStorm's autocomplete and various time-saving features.

Autocomplete is one of the many things that pisses me off in editors -- probably because I look at the screen and not my fingers. Half the time it screws me up by hiding crap I'm trying to refer to, accidentally selecting the wrong word, or just plain taking longer to decipher/use than it would for me to JUST BLOODY TYPE THE BLASTED CODE IN!

But there are many "features" people talk about that are outright annoyances that get in my damned way -- the illegible acid trip that is colour syntax highlighting, tabs shoving everything into one window with no option to detach them so I can move them to +SHOCK+ another display, tag completion putting closing tags in the wrong damned places forcing me to waste more time editing code I could have -- again -- just typed in properly in the first huffing place.

Don't even get me started about the chazerei that are preview panes, project management tools (aka crutches for people too stupid to use directories and meaningful filenames), and a whole host of other bits of trash that actually seems to make people waste time doing everything except actually writing efficient working code.

But what do I know? I consider "Flo's notepad 2" to be the pinnacle of coding editors regardless of what language I'm working in.

Admittedly my having programmed for around a decade before most such assistance even existed and two and a half decades before it was commonplace? Nope, doesn't influence my choices at all.

Me "Sorry, I won't use BEM because it bloats your site." Client "Does it cost anything extra?" Me "Yes, $2,000 more because I have to spend more time wrestling with CSS specificity."

ME: "No, because it means I'm writing anywhere from 1/2 to 1/10th the markup, no more or less CSS, leverage semantics so that specificity is a non-issue thanks to targeting semantic tags off the parent and actually knowing what selectors are... and even if it had cost more the end result is simpler, smaller, easier to maintain whilst still delivering the same or better functionality."

Your claim of "wrestling with specificity" holding water like a steel sieve. I hear that's the best kind... of sieve.

The laugh being you then point at turdpress and scam artist whorehouses like themeForest as being somehow worse -- to me those are no different than the garbage people vomit up with BEM and have the unmitigated gall to call a website.

... oh, and don't expect the push for broadband to make all that big a difference when the copper for the old speeds still hasn't been paid off.

Also quite telling you isolated it to "lah dee dah for the US" when I started out mentioning Chile, Mexico, Canada, and Australia... places where the greed of the ISP's are as if not more at fault than the infrastructure. Says a lot about your worldview.

Or are you one of these eastern Europeans who think that Canada and Mexico are part of the US. Kind of like the folks in the US who think that the Amazon is in Africa.

Dan W.

Oct 10, 2018

Jason Knight

In your example:


<div id="top">
    <h1>Site Title</h1>
    <input type="checkbox" id="mainMenuShowHide">
    <label for="mainMenuShowHide"></label>
    <ul>
        <li><a href="/about">About</a></li>
        <li><a href="/blog">Blog</a></li>
        <li><a href="/contact">Contact</a></li>
    </ul>
</div>

Client: "We are changing the layout of this section and adding some stuff."


<div id="top">
    <div class="wtf-flexboxcontainer">
      <h1>Site Title</h1>
      <input type="checkbox" id="mainMenuShowHide">
      <label for="mainMenuShowHide"></label>
    </div>
    <div class="wtf-flexboxcontainer">
      <div class="wtf-flexboxcontainerchild">
        <h2>Site Menu</h2>
      </div>
      <div class="wtf-flexboxcontainerchild">
        <ul>
            <li><a href="/about">About</a></li>
            <li><a href="/blog">Blog</a></li>
            <li><a href="/contact">Contact</a></li>
        </ul>
      </div>
    </div>
</div>

Me: "AWWWWWW, Sh#$%@$@ttt, some guy before me wrote #top > ul > li and it no longer works, so I gotta refactor!!!!"

With BEM:


<div id="top">
  <h1 class="top__sitetitle">Site Title</h1>
  <input class="top__checkbox" type="checkbox" id="mainMenuShowHide">
  <label class="top__mainmenushowhide" for="mainMenuShowHide"></label>
  <ul class="top__navmenu">
      <li class="top__navmenuitem"><a class="top__navmenulink" href="/about">About</a></li>
      <li class="top__navmenuitem"><a class="top__navmenulink" href="/blog">Blog</a></li>
      <li class="top__navmenuitem"><a class="top__navmenulink" href="/contact">Contact</a></li>
  </ul>
</div>

Client: "We are changing the layout of this section and adding some stuff."


<div id="top">
  <div class="top__flexboxcontainer">
    <h1 class="top__sitetitle">Site Title</h1>
    <input class="top__checkbox" type="checkbox" id="mainMenuShowHide">
    <label class="top__mainmenushowhide" for="mainMenuShowHide"></label>
  </div>
  <div class="top__flexboxcontainer">
    <div class="top__flexboxcontainerchild">
      <h2 class="top__navmenutitle">Site Menu</h2>
    </div>
    <div class="top__flexboxcontainerchild">
      <ul class="top__navmenu">
          <li class="top__navmenuitem"><a class="top__navmenulink" href="/about">About</a></li>
          <li class="top__navmenuitem"><a class="top__navmenulink" href="/blog">Blog</a></li>
          <li class="top__navmenuitem"><a class="top__navmenulink" href="/contact">Contact</a></li>
      </ul>
    </div>
  </div>
</div>

Me: No problem. Easy peasy. No need to worry about existing styles even though DOM structure changed.

Case closed. BEM is here to stay.

Jason Knight

The less code you use, the less there is to break

Oct 11, 2018

It's funny, you say "get around inheritance" where I would be saying USE inheritance. If derps slopping together code any old way would STOP thinking in this widget/modular bullshit and just focus on ACTUAL HUFFING SEMANTICS and SHOCK* ACTUAL HUFFING LOGICAL DOCUMENT STRUCTURE you wouldn't have the types of issues that result in all the lame excuses for trash like BEM.

... and seriously, if you're assigning sufficient values in your CSS that overriding by child is an issue, you're overstyling or wasting time assigning values that shouldn't be assigned. AGAIN the type of coding that results in vomiting up two to ten times the markup two to ten times the CSS, and twenty times the scripting needed. (assuming scripting should even be there).

Whilst yes, the fancy combinators (+, >, ~) are handy and have uses. we went two decades without them just fine. Only people who rejected semantic markup and separation of presentation from content seem to have ANY of the 'worries' you mention.

Of course the moment you say "modular contexts" I glaze over thinking "oh for Odin's sake, not this trash AGAIN"... since that type of development inherently pisses on accessibility via pissing on semantics. There are a LOT of ALLEGED experts out there running their mouths about how "great" BEM is; but to the last they write -- AGAIN -- two to ten times the code needed. How the blue blazes is writing two to ten times the code EASIER!?! That's the part I flat out do not understand nor is it likely I ever will. It sets off my BS alarm louder and faster than a 3AM tweet from the "orange cheeto-fingered moron in chief".

In four decades of programming I've seen this nonsense many times before... and it's always the same "we can't be bothered to do it right, so screw it" attitude that does nothing but create MORE work, with a result that doesn't meet the proper objectives, is harder to maintain, and most always has a service life measured in months before something goes bits-up face-down.

Though I'm wondering if something went wrong with your last post, since it feels like there are parts outright missing. That or I'm choking on the incomplete thoughts. Basically I have the opposite of what Emil mentioned: I have a nasty case of TSDR. Joe forbid anyone finish a sentence.

Side note, might also be nice if you answered my question as to what your two code snippets have to do with each-other since in one you have both div wrapping a H2 and P, in the latter you have the DIV wrapping the UL for Freya only knows what without those other two tags.

Making your examples of why BEM is so great utter and complete gibberish.

Dan W.

Oct 11, 2018

Jason Knight

RE: Code example

It's called sleepy head syndrome. Chill out and stop picking on it. You could've guessed what I was trying to say if you had the slightest idea of the BEM benefits. In any case, I edited the original post. I know you won't like it but did it just to make a point.

How the blue blazes is writing two to ten times the code EASIER!?!

It is easier because I don't write most of them at all, and I don't need to even think about specificity. It eliminates all the things you need to think about otherwise. I let autocomplete feature dynamically pick up existing class names so I can just select from a dynamic list and skip the hassle of memorizing or referring to them. You say ten times the code. That's like 4k vs. 40k in the day of several MB/sec. There is no perceived effect on any of it when people browse BEM-enabled sites. Human time is far more expensive than machine time. Anything that eliminates the need to worry about details helps developers.

I would argue that, after reading all your comments, you have an extremely condescending, extremely elitist and engineering-centric view of the world. For many people (and I am one of them), BEM is a natural way of eliminating potential confusion to begin with, and tut-tutting at developers for not considering the burden BEM's longer text might place on the computer strikes me as a bit odd.

It reminds me of John Markoff’s “What the Dormouse Said,” a history of the early personal computer industry and how your stance reminds me a bit of the thinking that ultimately sunk Douglas Engelbart’s visionary but incredibly complicated NLS (online system). Engelbart didn’t consider it all that necessary to develop an easy-to-use interface because he felt that people invested years in learning human languages and therefore investing six months in learning his system’s powerful, language-size command structure should not be a big deal. It’s an interesting argument when you think about it that way, but it ultimately doomed his design to obscurity, while his proteges who left for Xerox PARC and designed a system people could learn to use in an hour went on to change the world. Frictionless development experience is paramount; engineering concerns are secondary. And, quite frankly, fussing over some minor semantic oddities wastes time and energy when computers can and should cover our tails for us.

It is why WordPress is ruling the web no matter how some fussy developers complain about its codebase and the wild west of premium themes sold at ThemeForest. Sure, maybe many of them could be a little leaner. Sure, perhaps some of them are bloated. So what. People want them, buy them and use them because it's EASY, and it WORKS for them without having to fuss over technical details. People aren't going to care or want to understand HTML semantics. Design means drag and drop and dump some text and images in. It works for them, and we should give it to them! And, Google indexes WordPress-driven sites just fine despite supporsed failings in the codebase, so nobody cares. And not to mention developers need to make a living. Anything that allows them to slap together a solution in record time means massive profit. For that, BEM is only a fraction of what the industry is going for. Someday, we might not even need to think about any of it at all!

Anyway, seriously, in this era of computing power, is adding even 200k to a single page really such a strain on the average computer and Internet connection? Your argument is like saying we should walk instead of driving a car because walking doesn't pollute environment. We might as well go all the way back to the stone age in that case. If anything, it seems to me that we should be evolving toward more sophisticated techniques that can take advantage of modern processors by automatically taking care of the kind of fusses you are talking about here. BEM makes it simpler for coders to manage HTML pages because they don't need to worry about refactoring as things change.

Jason Knight

The less code you use, the less there is to break

Oct 12, 2018

Dan W. I have to say at least your arguments are meatier than the claims MOST people use about things like BEM, SCSS, etc, etc.

Sadly they still are the exact OPPOSITE of my experiences in programming the past four decades and working with HTML/CSS/JS for half that.

if you had the slightest idea of the BEM benefits

Which I do NOT understand any alleged "benefits" of BEM hence my being unable to decipher your example. You haven't provided any example that actually makes sense or isn't cherry picked/card stacked into being a fallacy. I'm not flipping psychic!

As to your "changes" the code in either example is STILL bloated trash filled with classes (and now possibly DIV) for NOTHING I can fathom in terms of layout requirements. Generally I would deliver a Sean Connery style back-handed slap to anyone that would deploy either sets of code present.

Though I'd have to see the desired layout result to say for certain on that... but some of your div placement would also break the functionality of the mobile menu (if using the scriptless CSS-only approach), IF all those DIV were 'necessary' I'd move the input for the show/hide before all the DIV.

Again, NOT that I think most of those DIV serve any purpose. What are you doing to the H1 and hamburger icon that require a DIV around them? What are you doing to the H2 that requires it's own DIV? What are you doing to the menu that requires it's own div? H1, H2, and UL are perfectly good block level containers and it is rare this slopping of DIV and classes willy-nilly in there is actually required!

Just as not every ejaculation deserves a name, not every blasted element needs a DIV around it!

But again, guessing since I've no clue what style / layout is trying to be implemented. I'm just skeptical and suspect broken/bloated/outdated site-building methodologies which is why you actually think BEM serves a purpose.

What was it my dearly departed friend Dan Schulz used to say? "The people who used to use endless pointless tables around everything now just wrap endless pointless DIV around stuff."

Again, guessing, but at a glance that's my suspicion. PROBABLY because mostly well written markup should be static with semantically neutral containers (DIV, SPAN) used sparingly for grouping and little else. Sure there are reasons like assigning semi-fluid layout inside a full width container, but that's usually the job for a single outer div, not three extra "DIV for nothing" inside it.

ESPECIALLY with the use of PRESENTATIONAL CLASSES saying what you want things to look like or their assigned CSS, and not what things ARE! What things are grammatically and semantically being the entire reason HTML exists, why CSS is separate from it, and why we have media targets.

AGAIN reeking of the "perfectly sighted users sitting in front of screens and f** everyone else" attitude.

engineering-centric view of the world

You say engineering like it was a bad word! What would you have me use? A lassiez-faire attitude based on lies and ignorance rooted in such mind-numbing stupidity as faith?

Joe forbid web developers embrace good practices or try to adhere to a code of ethics. YES, my engineering background greatly influences my practices and views -- because I realize I don't want the suspension on my car designed by an artist who doesn't know anything about materials, load tolerances, geometric balancing, forces, or any of the dozens of other things required to make it safe.

... and whilst yes, web development doesn't have the safety requirements of an automobile, telling large swaths of potential users to "suck it" just because "wah wah, I can't be bothered to use HTML and CSS properly" is, well... unethical. But don't look for ethics, a healthy work ethic, or compassion for one's fellow man in the 'hive of scum and villainy' that is web development; where every two-bit huckster and cut-rate carnival barker seems to just be out to drain people's wallets using as little effort as possible.

I often really think web development could benefit from something like this:

nspe.org/resources/ethics/code-ethics

But then on the whole ethics in development seems to be entirely unknown, what with the endless lame excuses, sleazy shortcuts, and "wah wah, somebody said something negative" attitude that lets every snake oil peddler on the planet peddle their wares to the ignorant, the hopeful, and the apathetic.

Anyway, seriously, in this era of computing power, is adding even 200k to a single page really such a strain on the average computer and Internet connection?

If that's really the case, why bother with whitespace minification? why bother with gzip compression? I mean seriously, what's a couple hundred k?

Of course you focus on the client-side but omit crappy connections or simply seem to think that making bloated wrecks large swaths of users cannot use is going to magically make infrastructure appear out of thin air. It's -- again -- a lame excuse I've been hearing for twenty years that STILL isn't any more true than it was in 1998.

Again, so many of your comments are comic gold, since your arguments to defend BEM often run directly against all the other "good practices" everyone is doing.

Hence why I don't know whether to laugh or weep when I'm called in to fix accessibility issues (like the client I'm currently revising code for) on a website where some derp using BEM, frameworks, SCSS, etc, etc has vomited up 512k of CSS and 90k of markup -- but hey, at least they minified everything without maintaining a uncompressed master copy... all to do the job of 16k of markup and 28k of CSS. (What I have right now; just finished the rewrite!)

Because I'm so sure the ~30k saved during minification was just SO worth the effort compared to the time it took (~20 minutes) to make a rewritten base template with near identical functionality chopping 557k off it.

And that's before the 816k of JavaScript spread out over 27 files I've kicked to the curb for them.

You also seem to be focusing on JUST the client-side load -- when dealing with thousands of requests a second that 200k magically becomes 200 megs -- which in most cases results in server-side processing having more work to do since what's outputting the markup again? More markup means longer pasting crap together, which can be the difference between using a low end VPS and having to move to the cloud. Worse, it often results in people throwing good code after bad with things like Varnish web cache that often causes more problems than it solves, all because "wah wah, I dunz wanna use teh HTML's currectlie"

Resulting in the type of clients I deal with almost exclusively now who have been utterly screwed over by the practices you are defending!

As evidenced by a client last year who was being fined $26K Euro a DAY for failing to meet accessibility norms, that was spending three times what they needed to on cloud and varnish and all other sorts of crap when they have a flipping in-house blade server as their main host! Had their own data center and STILL resorting to every trick in the book -- other than good code -- all because the people who made their front-end used garbage like BEM, frameworks, and said "well it looks good on our screens"... but yeah, database is the real bottleneck, sure it is.

Also doesn't even touch on the JS performance issues chewing on people's batteries and making users intentionally block scripting that having too many DOM elements and classes can imbue, particularly with blink's habit of maintaining active lists of all of them all the time so as to use up memory in exchange for faster execution time.... resulting in slower execution time when you start slopping in endless pointless DIV and classes for nothing.

Only exacerbated by the dumbass practices set forth by trash like jQuery of using bloody querySelectorAll-style methodology every blasted time you want to hook an element to do something.

Dan W.

Oct 12, 2018

Jason Knight

Now you are throwing SCSS into the mix of what you call "dumbass technologies." Do you realize that essentially speaking, you are calling out hundreds of thousands of people who affirm the benefit of BEM/SCSS and using them daily in our industry? Are you suggesting that the majority of commonly used technologies and methodologies are dumb and unnecessary!? That's a huge claim you might want to reconsider. It starts to sound like you are the only elite who knows what's right for the whole industry and everyone else is doing it wrong.

As for the code example, I was thinking of flexbox tweaking situations most of which require div for grouping, but I'm not going to elaborate on that anymore. It's a waste of my time at this point.

Re: "Not just the client side."

I give you that you have a point there, but I can brute-force my way out of it with Amazon AWS/CDN, so it sounds like an easily-solvable problem to me. That said, though, the number you presented sounds suspicious; how is it possible to manually hand code a 512k CSS into a 28k CSS, and a 90k HTML file into a 16k HTML? You must have cut down a lot of features, did just the layout at face value and called it even. That is not a fair comparison. There is just no way to hand code 512k of text in only 20 minutes. It usually takes at least several hours for an average frontend coder to code a beautifully-coded, Bootstrap/BEM template like this:

shuvohabib.com/charity-theme/app

It loads pretty quickly for me, and there aren't that many lines of code in there despite BEM/Bootstrap, either. What's the problem?

Why is jQuery a "trash" when it saves human time and effort? Sure, you could write a vanilla JS to do the same things, but why would you want to do that when slapping an 82kb (minified) package to an HTML file would save hours of your time?

Haven't you considered that BEM/SCSS and other modern tools/tricks can increase code quality by reducing the chance of making mistakes? Ex. BEM/SCSS eliminates the need to think about specificity and inheritance for the most part. I said it before, but it simplifies workflow by removing factors that can cause CSS rule conflicts and nesting confusion for human reasons. It, in turn, reduces the chance of making mistakes. And, most importantly, these things allow you to write code faster by removing the need to worry about details. With BEM, it's all classes. No ID, no nesting, just one flat level specificity that is so easy to locate, change and override. I'm saying that it's not just about the amount of code. It's also about engineer's brain cognitive resources, ease of use and time/budget constraints. Have you considered the angle where maybe, just maybe, we should find a way to brute-force our way out of extra coding and let computers help us save time agonizing over coding details rather than trying to save a few kilobytes here and there, so machines have fewer things to do? Big companies have money to spend, so why not use it to save our time and brain?

Jason Knight

The less code you use, the less there is to break

Oct 12, 2018

Are you suggesting that the majority of commonly used technologies and methodologies are dumb and unnecessary!?

YES. ABSO-FRAGGING-LUTELY. Hundreds of thousands of people were duped by Amway and Mary Kay, doesn't make them any less of a scam. Thousands of women shove jade eggs up their steamed clams. The majority of people voted for Clinton or Trump. (aka two candidates, one cup, congrats America, you're the cup). There are a whole chunk of society dumb enough to believe vaccines cause autism, that the "organic" foods movement is anything more than a marketing scam, or that ignorant halfwits like the "Avocado" or outright quacks like Dr. Oz have any clue what they're talking about.

... and the majority of people believe in a fairy tale about a magical man in the sky; doesn't mean there's a lick of truth in it! You hear it from evangelicals all the time: "But 2.2 billion people believe in Jesus, they can't be wrong!" -- completely omitting the other 5.6 billion people on the planet who beg to disagree. It's nothing more than card stacking mated to bandwagon.

I view a lot of these hot, trendy, and popular development systems that ALLEGEDLY are SOMEHOW magically "easier" in the same light. They use the words but their claims compared to the result are most always in direct conflict with my experience and learning.

Just because all the other lemmings are running towards the cliff is no reason to take the cyanide laced yogurt in hopes the aliens trailing Haley's comet will take you off to heaven.

That's one of the classic fallacies people fall into -- the mob more often than not is wrong, suckered in by a slick presentation based in zero actual facts.

Bandwagon, one of the seven classic propaganda techniques used to herd the majority around like sheep. Just like the card stacking, glittering generalities, transfer, plain folks, testimonal, and other bald faced lies of omission and manipulating of feelings instead of appealing to rational thought.

beautifully-coded, Bootstrap/BEM template like this:

Steaming pile of broken inaccessible garbage. That's the type of crap I'm constantly having to clean up for clients, where the white text over the image with insufficient text-shadow is effectively illegible for a good third of the population, the cyan on white and grey on cyan are far below accessibility minimums (kind of like the green submit buttons here on hashnode, at least I think it says submit), the undersized thin-glyph fonts, non-elastic layout with pixel metric font declarations flipping the bird at accessibility norms, and COMPLETE lack of navigable document structure. Even the logo looks more like a rendering error than intentional design -- lemme guess, done by the same guy who made the London Olympics logo that looked like Lisa Simpson going down on Bart and suckered the Olympic Commission out of millions in the process?

From a design standpoint before we even get as far as the code, it's an epic /FAIL/ at design no matter how pretty it is. It REEKS of being slopped together by an artist under the DELUSION they are a designer who doesn't know enough about HTML, CSS, accessibility norms, emissive colourspace, Luminance, guidelines or specifications to design but two things.... and Jack left town.

Code-wise the markup is not as bad as I'm used to dealing with from a bloat standpoint, but it still reeks of incompetence and general ignorance. See the X-UA nonsense that if 'needed' just means your HTML and CSS is written wrong, lack of media targets, blocking scripts in the HEAD, scripting for nothing, pointlessly redundant HTML 5 structural attributes that no legitimate UA actually leverages, endless pointless classes for nothing, lack of media targets on the stylesheet links, presentational images in the markup, utter and complete GIBBERISH use of numbered headings telling users with accessibility needs to go plow themselves, SPAN doing heading's job, Headings doing STRONG's job, missing heading levels, headings where utterly inappropriate as they are not starting new subsections (an utter laugh when some HTML 5 is used, but not the tags that even allow for more than one H1 to make semantic sense on a page!), empty alts with no corresponding text, and of course JS pissing all over the place for Christmas only knows what.

Just take this section:

<h2 class="block-title">Our Mission</h2>
<h4 class="mission__subtitle">Charities and Partners collaborating and sharing open solutions and ideas to create value in the digital space.</h4>
<h3 class="mission__invitation">If you are a charity or a supplier, we are ready to welcome you.</h3>

Pointless classes for NOTHING, and what makes anything there other than the H2 the start of a new subsection of content to be labelled? You know, the MEANING of H3 being the start of a subsection of the H2 before it and H4 being the start of the (missing) H3 preceding it? If you don't know what's wrong with that code, you have ZERO business writing a single line of HTML, much less arguing this point!

Which again is why it's 11k of markup doing 5.5k's job... on top of the blatant and obvious accessibility failings stemming from a lack of grasping the most basic of WCAG concepts and an equal measure of failing to comprehend semantics. Probably take me five minutes to re-do the markup of that one page and around 10-15 for the CSS.

... and why when I see things like this:

height: 80px;

and this:

font-size: 14px;

I assume a certain degree of ignorance -- note that ignorance in this case is not meant as an insult. It means whoever did it doesn't know better than to tell users (like myself) to BOHICA. You can fix ignorant. End result is sending me diving for the zoom to then encounter a broken layout.

But then even this:

@media only screen and (max-width: 1300px) {

Is enough to make me question competence and/or understanding of CSS. Pixel metric in a text filled layout, and NOW they finally decide to target screen media? The latter being too little, too late and a total failure to grasp one of the key concepts of using external stylesheets.

Hence if you don't have media="" on the LINK, or if you set media="all" it's an instant /FAIL/.

Whoever wrote that HTML is unqualified to write HTML for a serious project. They don't even know what the number in numbered headings are for, EVEN using the utterly banjaxed dumbass HTML 5 rules. Laugh being the footer text even says it's a collaboration, so that's multiple people unqualified to work on things.

Which is why if you deployed that for a bank, or healthcare, or a public utility, or a government organization, you're rolling the dice on how long it will be before you end up with a prosecutor or ambulance chaser knocking on your door.

Though here in the colonies sleazy con-artists and ignorant twaddles are getting an easier time of that now that the orange cheeto and his suck-ups in Congress are gutting the ADA. The move to outright make civil lawsuits for accessibility issues illegal being one of the biggest dirtbag moves this side of "Screw handicapped ramps" -- but after 20 years I know this trend well, and the pendulum is likely to swing back and forth many many times in the coming decade.

Bottom line, methinks we have radically different definitions of the word "Beautiful" means, much less what "Beautifully coded" is.

Kevin C.

Re-learning after an 8-year hiatus

Oct 12, 2018

Dan W.

I appreciate your enthusiasm, but having read all the comments so far, I have to say that Jason offered a series of the most compelling argument against using BEM, and I found everything he pointed out to be in line with W3C standards and other sources I referred to with regards to good coding practices. At least, you've got to admit that writing CSS the BEM way is quite tedious. After posting my question, I kept looking into this subject, and I've already given up on BEM for the most part. I'm still open for corrections and learning, but the more I tried to write that way, the more I felt like it went completely against the basic premises of CSS; CASCADING nature of it allowing us to skip labeling every single element with class names. Right now, I fail to see why I need to liter my HTML with super-long class names when there is no need for it. And I disagree that developers have trouble tracking which classes are what. I actually find it easier to keep track of things by having a combination of good DOM structure and a bare minimal amount of IDs and classes only where they are legitimately needed. I'm FAR from being an expert at this stuff, I was away from all of these things for eight years, and I still don't think it's as confusing as you seem to suggest.

Furthermore, I will also say that a lot of what you said about your approach in general sounds reckless to me. Your whole tone sounds to me like you are more into slapping together a quick solution and make easy money off of it. Am I getting you wrong here? Quite frankly, and I am just sharing my honest observation, what you are saying sounds much like a rogue auto repair shop charging money for rebuilding a transmission that didn't need that level of repair, making it worse in the process and demand a full replacement to "brute-force a solution" when the owner of the car found out that the rebuilt transmission didn't work. I prefer craftsmanship and care for things like this, and that's why I asked about it in the first place so that I can learn what to think about various techniques.

No offence. Just saying. Regardless, thank you for your insights.

Jason Knight

The less code you use, the less there is to break

Oct 12, 2018

Would you still call it garbage?

Given the website it's on is immediately in violation, it doesn't speak well for it. Given that it's loading four stylesheets with no media targets? That X-UA nonsense no well coded site needs? (at least not for 'edge-only') The blocking scripts in the head? The endless pointless classes for nothing? The endless pointless DIV for nothing? The nonsensical aria role that doesn't even point at a corresponding element? The JavaScript doing CSS' job? The static scripting only elements in the markup? (both are violations that automated testing tools miss) The derping of JavaScript for text size control instead of building elastic and scripting only menu functionalities -- aka MORE violations (depending on who's interpretation of the WCAG you're going with) automated testing misses. (and is an automatic violation of the additional requirements commonly used in Britain), incomplete forms, abuse of placeholder, gibberish assignment of numbered headings (an outright attempt to bullshit automated testing!), paragraphs around non-paragraph elements. (Just because something is text doesn't make it a grammatical paragraph), pointless horizontal rules where their semantics are inappropriate (and on my braille reader breaks the H3 to H2 navigation relationship), shoving new windows down users gullets with the (once deprecated for good reason) target attribute (that's still an accessibility no-no), incorrect/invalid usage of the ADDRESS tag, incorrect/invalid usage of STRONG (since a company name is not a grammatical case for "more emphasis"), lack of HR where appropriate, footer links with zero semantics resulting in a run-on sentence (something I'm completely unfamiliar with writing,,,,,,,,,), lack of graceful degradation on many of the links since no legitimate UA's in circulation give a flying purple fish about Aria... Title meta is redundant to title tag, 90% of those icon sizes will go unused and/or should be issued via manifest instead, not one legitimate UA gives a flying purple fish about the Author meta, and the non-standard initial-scale because they're too stupid to use EM and just pissed all over the place with pixels? Classic. Also considered a WCAG violation in some circles if you aren't using Opera 12/earlier as the only target device -- since proper browser behavior for scaling pixels is now dead and buried... NOT that EM is fairing much better which is why more and more of the web is telling the visually impaired to BOHICA.

The pointless redundancies are also laughable, like the "skip to content" link 1997 style as if they weren't using the (equally pointless) NAV and HEADER tags, showing they don't even know what logical document structure is. (or how BOTH of those are redundant to just using H1..H6 and HR properly, but then I could accuse the WhatWG of the same shortcoming!)

So yeah, 18.5k of markup for 3.4k of plaintext and two media elements -- with a slew of JavaScript telling users to suck it that I would immediately axe. Not even 9k of HTML's job.... and that's before talking about the 200k train wreck of ineptitude and incompetence that is bootcrap. Anyone came to me with that as a client, I'd suggest finding a stick to scrape it off with before tracking it all over the Internet's carpets.

But then bootstrap is in and of itself in violation under any meaningful interpretation of the WCAG -- though lots of people like to ignore those details when duping clients into THINKING they are being taken care of. (and then it's the job of a defense attorney and a consultant like myself to tell them they were saddled up and taken for a ride!)

See just a simple section of code like this:

html{font-size:10px;

Instant /FAIL/ -- they basically just disabled EM's functionality and pissed on accessibility. No wonder they thing that stupid malfing +/- font-size scripting reliant trash is worth crapping into pages.

No sir, I don't like it

No sir, I don't like it.

They talk a good talk, but they don't walk the walk. In any situation where accessibility guidelines are required, that site would fail -- even if the automated tools for checking aren't smart enough to pick up on it. It also fails MISERABLY on code quality grounds.

Your utter lack of empathy for imperfect developers (by your standard) is staggering.

Whilst your lack of empathy for the site owners screwed over donkey-show style by these bad practices, invalid to nonsensical code, and the significant chunk of potential users for whom many of the things you advocate are a decade or two away from even existing for them? That's what's truly staggering.

You wanna see a donkey show? "View Source".

Of course, pure comic gold that you accuse me of being the luddite, or complaining how 'experienced' developers won't embrace so-called 'modern' tools. That's because we've seen this stuff before, it was called 1997. We've spent twenty blasted years getting AWAY from that garbage to produce quality sites, but a whole new generation of nubes and rubes just have to cream their panties over HTML 3.2 style browser-wars era mindset and methodologies.... and then pat each-other on the back over how "modern" they are.

Jason Knight

The less code you use, the less there is to break

Oct 13, 2018

Dan W.

Simply NOT TRUE. It's about being smart in my trade and giving an excellent value/price ratio to clients. I can't charge $5,000 for something most people are unwilling to pay more than $2,000.

... and that's the fallacy on which all this type of trash is based, this noodle doodle LIE that somehow, magically, as if by divine will, NOT using BEM, not using frameworks, and using what the specifications, languages, and guidelines give us the way they were meant to be used is somehow harder to develop, harder to maintain, or will result in having to charge clients two and a half times as much.

Which is enough 100% grade A farm fresh manure to fill Biff Tannen's '48 Ford Super De Lux twenty times over.

I hate manure

The methods and processes I advocate take less time, result in easier baselines to work from, and increase the value of the result manyfold by not pissing on accessibility and maintainability from high orbit. UNLIKE the laundry list of "I cans haz intarwebs" that is bootcrap.

... and the only way you could think that one of these frameworks or garbage methods like BEM are giving you any improvements over those base languages, is that you learned them before you even gave the underlying language a chance or took the time to grasp the simplest of its concepts.

Again, how is having more code, writing more code, deploying more code, writing more complex code, relying on extra things that have to be learned on top of the basics, to avoid using the basics... "Easier"?!? BULLCOOKIES!

It doesn't lower the bar of entry, it raises it... and it is only through marketing, propaganda, lies, and exploitation of the ignorant that any PERCEIVED "ease" is created. At best it's a placebo, at worst it's a scam. Sleazy, lazy, dishonest, duplicitous, card stacked LIES.

That you then go on to outline the sleazy cookie cutter process used to scam unknowing potential site owners by fly-by-night dirtbags with all the business legitimacy of Don Lapre? Classic.

If a movement needs to be started, it's one to stamp out the predatory scam artists and know-nothings who run around exploiting others.

But again, that would require something known as "ethics" -- the enemy of modern society.

Dan W.

Oct 15, 2018

I feel like this whole BEM debate has exposed one crucial sub-topic: Developer elitism.

Developer elitism is real. Some elitists mistake difficulty or inaccessibility for rigor. They assume that just because something was hard when they did it that it should always be hard. Reading all the comments by Jason Knight in this thread again, I can't help thinking it is a classic case of extreme elitism at its worst. I remember being laughed at when I told more experienced colleagues back in the days I was still a beginner that the only coding I knew (at the time) was some HTML and some JQuery tricks. I wasn’t a “real” coder yet, and I will never be one, according to them, because I hadn’t learned how to write assembly code.

Elitists don’t like feeling threatened as the ultimate authority. When they see what they consider as unworthy newcomers to their field, they scoff and rant, just as @cutcodedown does in this forum. They scold at them and declare that they are not worthy of the industry and have "no business writing code." Even more maddeningly, these novices have access to tools and shortcuts that the elitists never had in their time. Therefore, novices are unworthy of following the path simply because they didn’t blaze the trail. And it gets worse when they find out that some of us are making thousands of dollars doing far less amount of work. They call us "a scam artist." Coding academics are about the status quo and protecting their ego.

Elitism grows out of arrogance mixed with insecurity. Elitists are only interested in being the source of the knowledge and blasting everyone else. Just notice how he is ALL about negatives, blasting others and calling names. It's obvious that the guy has an extremely low view of the rest of the world, and he must go on with his lengthy, convoluted rant against everyone and every methods and every technique suggested in this site. It's evident that he has absolutely zero interest in answering questions constructively or helping what he would call "nubes and rubes." His sole interest is to blast others and prove that he is the only worthy one to write any code. So much for Hashnode's claim to be a friendly place to ask questions. I don't know why they allow this type of aggressive, cynical, negative and condescending commenter around here.

We should not stratify coders into classes. Classifying them as "nubes and rudes," calling them "donkeys" "mouth-breather" and accusing them of "creaming their panties" does nothing but to alienate just about everyone who reads such statements. They don't realize that such "brutal honesty" is working against their cause because they have absolutely no empathy, utterly unable to imagine that, where there are methodologies, frameworks, tools, and there are hard-working individuals building those things.

Revered language experts don’t treat new language learners with any inordinate amount of disdain, as far as I know. Yet, this is often what happens to coders in our industry, especially new coders who are just trying to learn and be productive, even using some pragmatic approaches. They are essentially told that if they didn’t learn the code for the express purpose of loving the most obtuse and bizarre aspects of a language, then they are not “real” coders.

“No true Scotsman,” they might say, would fail to understand the advanced cultural-linguistic nuances of their native coding language. “If you haven’t written a compiler you’re not really a coder” sounds almost as silly as “If you haven’t written a dissertation on phrasal verbs, you’re not really an English speaker.”

I’ve heard all too many statements like these from elitists, especially some particular threads in this site. So have you. We should all welcome and encourage a flood of newcomers with very different coding methodologies and tools. Coding is a medium to solve problems. BEM solves some issues for many people. Bootstrap has helped hundreds of thousands of people despite its supposed bloat. We should applaud eagerness to find new methodologies and tools to solve practical problems pragmatically no matter how unreasonable and illogical it looks to some elitists doing it the same old inefficient way for the past 40 years.

I guess I will have to leave at that and move on from a series of public verbal abuse, lack of class and a complete absence of empathy in disagreement. I'm thoroughly disgusted with the whole discussion, and I'm sick and tired of it.

Sandeep Panda

co-founder, Hashnode

Oct 15, 2018

Hey Jason Knight

I sometimes agree with your comments and I think they are insightful. But I certainly don't appreciate the way you voice your opinion. We have a set of community guidelines to create a friendly and inclusive environment here. To be honest, your comments are flagged by the community members almost on a daily basis and I think it is justified.

I honestly don't care if BEM is the right way or not. You can have strong opinions and criticize people, but you need to do that in a respectful and constructive way. For example, take a look at the following lines from your comments/replies:

BEM is the type of nonsense the OOCSS fanboys cream their panties over.

I don't think the words cream their panties over add any value to the discussions.

Or are you one of these eastern Europeans who think that Canada and Mexico are part of the US. Kind of like the folks in the US who think that the Amazon is in Africa.

Again why would say that? Does it add any value? People have been offended by the above sentence and they have reported it. Now, instead of asking people to grow a thick skin, why not just refrain from using words that might offend certain sections of users?

Additionally, name calling such as "nubes and rubes", "Dumbass", "donkeys", "creaming panties over" etc don't create a friendly atmosphere. You might argue that you are not abusing the OP or another user who is arguing with you - but it's still offensive.

Beginner programmers who are just starting to learn to code shouldn't feel intimidated. We must create a friendly and inclusive environment and criticize constructively.

You can refer to the community guidelines here. Please note that you have been violating these rules for quite some time and we are not suspending your account because we are not big fans of banning people. That's why we are repeatedly asking you to follow the guidelines and be constructive in your comments.

This is not about just the replies in this thread. Your comments in other discussions regularly violate the guidelines. If you really want to enjoy using the community and create value for everyone, please follow our guidelines and let's make this a welcoming place, not a hostile one.

If users keep flagging your comments and we feel they violate our guidelines, we'll delete them. Repeated offense will lead to suspension of the account.

Jason Knight

The less code you use, the less there is to break

Oct 15, 2018

Sandeep Panda re-reading your community guidelines I actually fail to see where anything in this thread -- or any of my other posts on this site -- would fail to meet what's written there. That others apparently do is somewhat surprising; this is just conversational speech using similes, anecdotes, and colloquialisms. Aka humor.

I do wonder if folks are missing the humor, or are so offended by WHAT's being said they are incapable of seeing it.

When something is wrong I'm going to say it's wrong. When it's preying upon the ignorance of those just starting out, I'm going to SAY it's doing so.

In my experience most of the stuff I'm railing against does exactly that. It's PREDATORY. It takes advantage of people who don't know any better -- but JOE FORBID anyone DARE to speak out against it. There is no, nor should there even BE polite language for the sleazy, duplicitous LIES and fly-by-night attitude that allows people to "take the money and run" screwing over site owner after site owner, client after client, and website after website in the name of expedience and a quick cash grab.

LIES like their way being somehow easier. LIES like their way being somehow faster in development time. LIES like their way having better quality results. LIES like somehow magically ignoring all the underlying technologies they CLEARLY do not understand and slopping together off the shelf answers somehow makes them qualified to flap their yap on the topic.

Again why it's like dealing with cultists, fundies, homeopaths, nephropaths, and all the other liars peddling dimestore hoodoo.

Particularly when the practices people claim "lowers the bar of entry" for developers raises the bar of entry for who really matters -- VISITORS to websites trying to access CONTENT.

MORE SO when as I clearly illustrate MULTIPLE flipping times that those CREATING these systems do not know enough HTML to be telling others how to build websites -- something the fanboys have ZERO defense against which is why they are so "offended". Their best response is "who cares as long as it works" when it clearly doesn't work for many users -- but they can't see any further than todays quick cash grab; not giving a flying purple fish how many users it excludes, how many clients they screw over, how much they continue to promote ignorance and incompetence as the norm, or how badly it screws everything over TOMORROW. It's the credit mentality in action -- pay more later for something you can't afford now. NOT a great business plan.

The kicker being the lack of responsibility they take with their work, and utter disregard for accountability. The types who end up shocked when dragged into court for failing to meed accessibility or sued for damages when actual accountability comes into play!

Yes, those are actually things in this industry.

Instead they just keep on keeping on with their "This here's a story 'bout Billy Joe and Bobby Sue" attitude. Just call me "Billy Mack". You know he knows 'xactly what the facts is... he's not gonna let those two escape justice.

(that's called humor, it's quoting Steve Miller Band's "Take the money and run" -- which sums up the mercenary attitude that leaves client after client bamboozled!)

Also keep in mind, my posts tend to get as many upvotes as they do notifications, possibly more. Pretty sure I don't have over a thousand posts. Notice that at the rate I get appreciations I'm at three-quarters your count, and you're co-founder of this place!

... and that's because I'm often voicing what others are unable or unwilling to say because of the bullying attitude from a community that is in LOVE with scams, ignorance, and wishful thinking. Those advocating standards have spent decades accused being of pedantic, elitist, Luddites, and a whole host of other things when all we're trying to do is show simpler, faster, easier, more accessible ways of building sites that are also easier to maintain, whilst pointing out all of this OUTRIGHT GARBAGE is nothing more than preying upon the ignorance of Joe Sixpack and Susie Sunshine.

It ends up much akin to the Atheist who spends his life under attack shouted at and belittled by the mob, with every single bit of insulting language ... but when finally the straw breaks and they go to break a cross in half over their knee or light a bible on fire, the Deists immediately play the victim crying for "respect" and "civility"; Pathetic since by their actions and methodologies those claiming to be wronged clearly have NEVER shown any.

again, that's a simile, a natural part of conversational speech.

I'd also point out that -- and I don't know if you noticed this -- even my controversy has been GOOD for your joins, since it appears several users -- who shall remain nameless -- only joined this site to argue with me or attack indirectly, yet have little to no other activity. When you have someone who's been a member for 8 days and 90%+ of their activity -- including the very first thing they did -- has been nothing but getting butthurt over my daring to say bad things about their favorite tools, the competence of those who make them, and the lack of knowledge on the part of those who use them, well...

... and I've been nice and not gone around hitting "report" on them since, well...

, and take anything personally.

Though you may want to rewrite that section, it actually reads like you're telling people to take anything and everything personally. Honestly there are a number of sections so worded that cause undue ambiguity.

Oh, so I am in violation, I'm not taking it personally. Gotcha.

Jason Knight

The less code you use, the less there is to break

Oct 16, 2018

Sandeep Panda

No need to respond to this.

Yeah, can't have that -- oh noes, discussion on a discussion site. Might give me a chance to point out your fallacies as well.

I'm pretty sure Emil's ok with it too, seems a laid-back reasonable sort. Emil Moe disagree? Let me know, dont' want to speak for you.

Of course if you where was a PM system here we wouldn't be threadjacking. hint, hint, be a great addition to the site! Particularly since I don't think I've gotten any-sort of e-mails from you folks in like a year. I'd expect if you've been removing posts you'd at least tell me so SOMEWHERE. Right now in these threads seems to be the ONLY contact I have with your staff!

See that's your problem. You fail to see others' perspectives.

...and there's that fallacy. No, I just focus on a different group's perspective; that of the end user. Joe forbid people who's job it is to make websites focus on building websites actually useful to end users instead of saying "well non-sighted don't matter, and partially sighted don't matter, and those needing navigation aids don't matter, and people in places that don't have broadband don't matter, and mobile users with small data plans don't matter, and mobile users who still rely on dual core or less 1ghz or less phones because they can't afford the latest "iScam 10XS" don't matter." and the other endless stream of lame excuses for their trashy nonsensical gibberish practices. To the point that sooner or later they've excluded so many small groups of people as not being in their "target audience" there's nobody flipping left!

Doubled-down on by the fallacy the fans of these systems make about it somehow being "easier" or "simpler when they're just adding more to learn, encouraging bad practices, creating more work, with results that are harder to diagnose when things go wrong or maintain in the long term. But they're blind to that because it's all they know, and they've been told it's "easier" for so long so many times in the like-minded echo-chamber of head-bobbers you'll NEVER convince them otherwise. In the rare cases they even TRY to prove it is "easier" the baselines they compare it to are so horrifically and poorly written, it's painfully obvious they don't even know what "easier" is, and go rabid when you even suggest it. But again, don't anyone DARE to respond in kind.

But sure, I'm the one not taking different perspectives into account. There's a reason it's called "work" and not "happy happy fun time" -- and the perspective that should REALLY matter is the visitor to the site or user of your application, and not the "convenience" of people who for all intents and purposes are flat out refusing to do their job!

... and if I'm so vehement about this, it's not because it's "all about me" but out of concern for all the people these sleazy predatory practices screw over time after time after time. But sure, I'm not caring about other people when responding to those who say all the groups I talk about don't matter.

Search Hashnode