That eval() isn't evil()

😈

That HTML/CSS/JavaScript frameworks -- and front-end frameworks of every flavor -- are incompetent trash created by people not qualified to tell others how to use web technologies, and used by people who don't know enough about HTML, CSS, or JavaScript to even be working in the field in the first damned place. The same goes for the majority of new tags introduced in HTML 5.

EVERY single claim about them, such as being "easier" or "makes you more productive" or "helps you collaborate with others" is 100% fiction. A level of bullshit rarely matched outside of religion and politics... which is why the fanboys of halfwitted nonsense like bootcrap, jquery, react, vue, less/sass/scss, etc, etc, sound more like kool-aid sipping cultists than sane and rational adults.

Writing two to ten times the HTML needed to do the job is NOT any easier! Starting out with ten times or more the total code your page should have before you've written a damned thing does NOT make you more productive. Thumbing your nose at the entire reason HTML even exists, why CSS is separate from it, and adding something else to learn on top of the underlying languages does NOT increase the pool of developers you can collaborate with!!!

The ONLY way you can see legitimate benefits from their use is a failure to understand even the most basic concepts of the underlying languages, as well as not grasping good practices like separation of presentation from content, semantic markup, and every other improvement in methodology HTML 4 Strict was trying to drive us towards... much less the original intent from when TBL created HTML in the first damned place!!! It reeks of ignorance and ineptitude, the latter being apparent even in the official code examples.

Take the outright incompetence shown in the bootcrap demo's such as:

    <body>

        <div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow">
            <h5 class="my-0 mr-md-auto font-weight-normal">Company name</h5>
            <nav class="my-2 my-md-0 mr-md-3">
                <a class="p-2 text-dark" href="#">Features</a>
                <a class="p-2 text-dark" href="#">Enterprise</a>
                <a class="p-2 text-dark" href="#">Support</a>
                <a class="p-2 text-dark" href="#">Pricing</a>
            </nav>
            <a class="btn btn-outline-primary" href="#">Sign up</a>
        </div>

        <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
            <h1 class="display-4">Pricing</h1>
            <p class="lead">Quickly build an effective pricing table for your potential customers with this Bootstrap example. It's built with default Bootstrap components and utilities with little customization.</p>
        </div>

        <div class="container">
            <div class="card-deck mb-3 text-center">
                <div class="card mb-4 box-shadow">
                    <div class="card-header">
                        <h4 class="my-0 font-weight-normal">Free</h4>
                    </div>
                    <div class="card-body">
                        <h1 class="card-title pricing-card-title">$0 <small class="text-muted">/ mo</small></h1>
                        <ul class="list-unstyled mt-3 mb-4">
                            <li>10 users included</li>
                            <li>2 GB of storage</li>
                            <li>Email support</li>
                            <li>Help center access</li>
                        </ul>
                        <button type="button" class="btn btn-lg btn-block btn-outline-primary">Sign up for free</button>
                    </div>
                </div>

Which as I'm always saying, if you don't know what's wrong with code like that, do the world a favor, back the hell away from the keyboard, and go take up something less detail oriented like macramé!

For those of you who don't know what's wrong with that... numbered headings do not mean fonts in different weights and sizes!!! An H5 indicates the start of a subsection of content of the H4 before it. As such it is gibberish semantics to have an H5 as the first heading on the page! H1 is THE (singular) heading that everything on every page of the site is a subsection of, as such "$0 / mo" and "pricing" doesn't really fit that description now, does it. You can only have more than one H1 semantically if you use HTML 5's idiotic and pointlessly redundant SECTION tag. Since I see no SECTION tags, on heading use ALONE the person who wrote that example doesn't know enough about HTML to be creating examples other people are going to copy.

Then of course the NAV with the run-on sentence inside it. Anchors apply no semantic meaning to their content, so lacking a unordered list inside that (pointlessly redundant dumbass) NAV tag is semantic gibberish and flipping the bird at non-visual user-agents such as braille readers, screen readers, and search engines!

... and that's BEFORE we talk the endless pointless idiotic haflwitted dubmass ignorant "classes for nothing" by way of the application of presentational classes. IF you're going to use classes like "list-unstyled" or "font-weight-normal" or "text-black" you might as well go back to writing that presentational HTML 3.2 with FONT, CENTER, ALIGN, and tables for layout you all so clearly miss! The very nature by with CSS frameworks function -- using classes to say what you want things to look like instead of WHAT things are or WHY they might receive style is mouth-breathingly idiotic bullshit! There are NO polite words to describe the levels of ignorance and incompetence shown by HTML/CSS frameworks!

There is NO legitimate reason for that code above to be more than:

<body>

    <div id="top">
        <h1>Company name</h1>
        <ul id="mainMenu">
            <li><a href="#">Features</a></li>
            <li><a href="#">Enterprise</a></li>
            <li><a href="#">Support</a></li>
            <li><a href="#">Pricing</a></li>
            <li class="signup"><a href="#">Sign up</a></li>
        </ul>
    <!-- #top --></div>

    <div id="pricing">
        <h2>Pricing</h2>
        <p>
            Quickly build an effective pricing table for your potential customers with this Bootstrap example. It's built with default Bootstrap components and utilities with little customization.
        </p>

        <div>
            <h3>Free</h3>
            <ul>
                <li><strong>$0 <span>/ mo</span></strong><br></li>
                <li>10 users included</li>
                <li>2 GB of storage</li>
                <li>Email support</li>
                <li>Help center access</li>
            </ul>
            <a href="#" class="signup">Sign up for free</a>
        </div>

Apart from the outright ignorance of even the most basic of HTML and CSS use, the meanings and purpose of every single HTML tag, or how to leverage CSS selectors to make styling pages a breeze. They actively encourage using twice or more the HTML needed to do the job, actively encourage NOT using CSS properly or even learning how to use CSS, and the resulting sites are inaccessible broken train wrecks that tell large swaths of users to go plow themselves!

But don't you DARE voice this opinion regardless of how politely you put it. (which is why I gave up being nice about it ages ago) It simply isn't socially acceptable to badmouth these things since they're media darlings. Their praises mindlessly sung and parroted like they were the huffing gospels.

It's why I consider the people who make these "frameworks" to be nothing more than scam-artists., and those who use them by choice to be little more than "Just another mark".

Based on my experience so far: quick and dirty implementations are come to stay. Often used to quick implement a feature, may for research purposes or to showcase a feature. Also often told to „make it right“ when it should do it into the product. But often this doesn’t ever happened.

So I have accepted that and my everyday goal is to implement the first solution quality wise as it should be and don’t take significantly longer than a quick and dirty solution.

Matt Strom eval() can be used in various situations. Just last week, I used it in order to execute script tags in HTML partials, which I received from my server and had to insert into the page using innerHTML. innerHTML does not execute script tags for XSS reasons since HTML5, which is useful in general, but has to be worked around when using static dynamic content from a source which I control and which is served via TLS.

Alternatively, I could have created a new script tag and appended it to the DOM, however that's a lot more work for a simple task imho.

Marco Alka

execute script tags

Something I wouldn't do...

innerHTML

Something I wouldn't do.

HTML partials

Something that shouldn't exist.

Those three things are really troubling in concept.

static dynamic content

The what now?!? Which is it, static or dynamic? Or is this like the Doctor reversing the polarity of the neutron flow?

I find it disturbing how often folks when doing things like AJAX will slop markup into the response to innerHTML it in. 20 years of good practices and sound advice down the drain.

Alternatively, I could have created a new script tag and appended it to the DOM

Better but...

Alternatively, I could have created a new script tag and appended it to the DOM, however that's a lot more work for a simple task imho.

Three lines of code is a "lot more work"?

NOT that your solution would work on any secure system anyways, since ALL scripting inside a <script> tag is blocked under the CSP if you're using that.

The content security policy is a great way to make people using JavaScript in wrong and insecure ways cry in their beers. "Wah wah, but I wanna" -- well tough! Doesn't work anymore.

Jason Knight there will always be requirements people can't do anything about. I wouldn't do partials, either, but I have to, and they are HTML, so innerHTML is the way to go, and they do contain scripts. Tell me a better way to handle partials, and I will gladly change my code :)

I ran across Jeremy Clarkes "Dry CSS" presentation: slideshare.net/jeremyclarke/dry-css-a-dontrepeaty…

If I understand your advice correctly, his approach would be a good choice for maintaining separation of content and style.

David Foote it would if it weren't for his use of presentational classes, COMPLETELY DEFEATING THE POINT of separation of presentation from content.

Since if you use half-witted dumbass classes like ".light-white-background" you have -- as I keep saying -- so completely missed the point of why CSS exists and what 4 Strict/semantics were trying to make us do, you might as well go back to not using CSS and using outdated outmoded attributes like BGCOLOR. That's OOCSS style bullshit -- and there are few things in HTML/CSS that are as outright mentally enfeebled as OOCSS. You want to talk about COMPLETELY missing the entire POINT of HTML and CSS, look no further than the pea-brained insipid vacuous train wreck of infacility that is OOCSS.

Your classes should say what things are or WHY they are receiving style, NOT what that style is... otherwise you're not separating a damned thing!

The reason for this is simple:

1) One of the entire reasons for CSS is to be able to run multiple skins off one markup. It doesn't make a lot of sense to have a class called "w3-red" if the text isn't red in all skins.

2) that style may not apply to all your different media targets. "red" or "light-white-background" is probably just going to waste ink or piss off people printing... It's certainly complete gibberish and a waste of bandwidth for non "screen media" targets.

Part of why if you don't have a MEDIA attribute on your stylesheet LINK tags, or use media="all" you've ALSO completely missed a significant part of the how/what/why of CSS. As point of fact, I use the lack of that attribute or sending to "all" as a indicator that the developer in question isn't qualified to write HTML or CSS.

3) You end up nesting together endless pointless classes on single objects -- one of by biggest complaints about front-end frameworks. This not only results in bloated markup, it ALSO means you're failing to leverage caching properly.

Same as how using the STYLE tag is stupid and it should be removed from HTML entirely. An external stylesheet can be cached across pages that share the same layout and style... or even if the same page is simply visited again. ANYONE telling you that using the STYLE tag is going to help your page load or render faster is talking out there arse. EVEN if it's Google PageSpeed saying it! That crap doesn't belong in your HTML.

HTML is for saying what things ARE; Grammatically, structurally, semantically... NOT WHAT THEY LOOK LIKE!

That attitude should extend to your classes and ID's as much as possible. That's why you shouldn't use the STYLE tag, and where possible you should avoid the style="" attribute since it too involves putting appearance instead of meaning in the markup. The only time I "allow" style="" into my HTML is when that style helps convey meaning -- a RARE corner-case such as for tag clouds or HTML+CSS bar graphs where things like width, height, or font-size is part of the content.

But yes, MUCH of the approach is sound -- before it was called DRY it was called "nesting selectors" and was just part of how we USED to use CSS before developers went full Pakled.

You never go full Pakled.

If you have multiple CSS targets that share values, you nest their selectors. That's nothing fancy warranting some fancy name, that's just common sense use of CSS.

It's also part of why garbage like SCSS "mixins" are a waste of time. We can already do that if you know how!

I had the same initial reaction, but then I realized that he was only using the presentational id and class to group the selectors against corresponding properties. His method would never include attaching the 'group-named' id or class against a target element.

OTOH when facing a new problem it's very rare to solve it right the first time. It would be a waste to spend dozens of hours on the wrong implementation.

I think, as usual, the problem is a matter of balance. Don't try to solve it perfectly, but at least try to organize your code and write comments for the intricate parts.

I honestly think it’s a thing that comes with experience and it can be learned. It’s simply a sum of previously gained experience which things worked out and which didn’t. Based on that you can write code that nail it or is flexible enough to fit right in if variables/circumstances on the outside are in the „flow“

But as many things, it doesn’t work out every time and even the most experienced devs screw up from time to time.

It’s something to work on every day.

Here's a nice article related to this: blog.codinghorror.com/rule-of-three

Thread

What controversial beliefs do you hold about programming?

Responses(3)

😈

Recent threads

Search Hashnode

What controversial beliefs do you hold about programming?

Responses(3)

😈

Recent threads