Do you think using Bootstrap and other CSS frameworks would make a developer look less competent? Yes, if you also tell others that it's the only way you know how to create a responsive layout, or if you claim that you love them and you use them as your primary tool. No, if you tell others that you primarily code responsive layouts without them, but you can handle them if someone requires you work with them. With Grid Layout and Flexbox support out of the box in CSS, do you think a developer shouldn't rely on frameworks anymore? What are your thoughts on this? To me, it's FAR easier and quicker for me to code manually using CSS Flexbox and Grid than using CSS frameworks. I can work with CSS frameworks, but the time and effort I need to spend overriding and customizing their defaults nullify the time saved using pre-defined components.

I'm a frontend dev. People most often think what I do is always cheap, fast, and I can build a full-custom database-driven website from scratch in a couple of days in my spare time for $200 max using a GUI drag-and-drop website builder.

... I want to learn some more frontend wisdom from Jason Knight , to be bluntly honest. I was ticked off at first, but he opened my eyes to the truth. But, it seems to me like he has gone away for good. So I have not logged in as much as I used to.

What are you talking about? I'm talking about how it will NOT work until you specify its element type. You add a display property and then you style. It doesn't count as "it works" when a div and span tag don't require it. How is that better than adding a class name to a div tag? Custom elements have no implicit semantics or keyboard support, and it is a massive problem, a massive middle finger for those who have accessibility needs. Millions of them, in fact. When you define a new tag, the browser really has no way of knowing if you’re trying to build a button, or a slider, or just a fancy text container. Adding these features requires a fair bit of work on the developer’s part and it can be difficult to reach parity with the native equivalents. It is just like how people say it's cool to litter HTML with "<div class="color-danger look-like-this">" style presentational classes just because it's technically legal to do so. Just because you can doesn't mean you should.

To use an autonomous custom element, all you have to do is type it in HTML syntax <like-this>. There's nothing more you need to do. Not exactly. Try <name-claim> and style it. It won't work. Besides, the custom element's purpose is to aid with web app development. (Web Components, etc.) It's not for naming your version of HTML and claiming it as if all browsers natively support them without some extra work. Again, as Jason Knight already explained, I dislike the implication behind this kind of idea. I don't see good enough reasons to use custom elements when it comes to authoring a website. Speaking of Web Components and Polymer, it's not all rosy: https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/#so-what-s-this-broken-promise-i-hear-about I guess we shouldn't have JavaScript because it's possible to write an infinite loop that will crash the browser. There are already tons of ways you can abuse HTML and write bad HTML without even making use of custom elements Absolutely. We have way too many frameworks and trickeries that put unnecessary giant weight on so many websites. JavaScript overuse is one of the significant reasons websites are often slow and buggy. I'm shocked to see the number of errors in my browser console nowadays. Let's start by removing that big Jumbotron slider, get rid of all the animated nonsense often done through JQuery, and remove all the stupid JavaScript files WordPress plug-ins inject on every friggin' page. Better, let's scrap WordPress, Bootcrap and countless CSS frameworks and make developers LEARN the foundations correctly. Mindless extensibility is one of many reasons people abuse HTML and write bad frontend code. We need to advocate RESTRICTION of such "extensibility mindset" because it's way too easy for developers to get into "the more, the better" mentality. We ought to consider whether something is so compelling that its trade-offs are worth taking. I contend that such technologies come maybe once every decade at this point. Besides, most of us just need to learn the basics a lot more than we do before jumping into "fancy" stuff. I know that's been the case with me. Fundamentals go a very long way. Most of us think we know, but we don't, really.

It's an interesting idea, but I believe that constraints are a blessing in disguise; I believe that working within pre-defined HTML specs eliminates a chance of running into unknown-but-potential issues and workarounds to remedy them in the future. To me, the gains of slightly cleaner syntax and "better" language features are not enough for me to deal with extra steps described in the whatwg.org page you mentioned, more complicated development considerations and potential issues as a result of doing more work. I prefer to stick to the minimum viable set of the official HTML 4 Strict tags and prefer not to mess with something as foundational as HTML elements. Furthermore, I am not a fan of the implication behind this kind of idea. It will be a matter of time before someone will start creating tags like <red-colored-container>, <all-text-italic-inside>, etc. all sorts of presentational crap, defeating the whole purpose of HTML as Jason Knight already explained earlier. Heck, I could even see some bozos crying out loud, "Wah wah I dunt wunna luarn how header tags work, so I'm creating my own!" and write <header-2-bold-italic> or something crazy like that. Have you considered that the "headline" text that's marked up as <jumbo-headline> might not be a "jumbo" "headline" text in the next website revision?

I prefer writing for HTML4 Strict and publish as HTML5 to take advantage of the concise header and some other tags that have legitimate usefulness. It means that I don't prefer using tags like article, header, footer, section, and aside because, contrary to conventional notions, they are semantically redundant and unnecessary. I would say that most developers don't bother studying W3C recommendations because they naturally learn on learning mostly from random tutorials and follow their own sets of rules, or they wouldn't embrace things like CSS frameworks and presentational CSS classes so blatantly. I don't use tags like articles, sections, etc. because all you need to do, when it comes to a fundamental document structure, is to structure your contents with all the right "h" and "hr" tags. "h1" is used only once as the title of the page, and everything follows (h2, h3 under h2, h4 under h3, and so on. It's like an outline with full contents). After that, it is a matter of using "div" tags only where it's necessary to group and style things. But I say, "ONLY where it's needed" because I can also leverage a lot of block-level tags to lay out blocks of things without them some of the time. "hr" tag is for things like a footer that don't warrant an "h" tag yet still need to be a section of a document. It is NOT about drawing a horizontal line. It is for a semantical meaning. You can render it as a line, or you can hide it with CSS (so it is still there for a screen reader) and wrap it around a div tag to create a little more visually extensive footer. HTML is for content and its structure, and CSS is for a presentation of the contents in the HTML document. The point of using both is to separate concerns. Your goal should be to write HTML as minimal and clutter-free as possible so you won't have to make any changes in the future when you need to change the appearance of the website. A ton of people will say it is unrealistic, it is not how we work these days, it won't work in a large-scale site, and so on. IGNORE THEM, because I found that the industry is so full of misinformation and the mindset of "newer and shinier, the better" and "Wah wah I dunt wunna luarn, I dunt wunna du hurd wurk" nonsense. CSS Zen Garden (http://www.csszengarden.com/) is a bit dated but still a relevant example. It is one of the examples of how separating concerns can be extremely beneficial in the long run. You should take a look and analyze what they are doing with HTML and CSS. You can do what those people did in their time a lot easier now thanks to CSS Grid and Flexbox. So many developers have forgotten the original intent of HTML and CSS presented in the site. We as an industry is now too busy reincarnating HTML3.2 presentational markup mindset with presentational CSS classes littered all over their documents. It's so bad that it makes Word War Z zombies feel like a charming fairy tale. To me, presentational CSS classes are rotten zombies worth shooting down right in their head.

Jason Knight The Berea Street website has this article: https://www.456bereastreet.com/archive/201603/why_i_dont_use_css_preprocessors/ It's making a compelling case. I find it liberating to know that we can be more effective in writing HTML and CSS without those additional tools. I don't need to use Sass and use variables. I can just write CSS in DRY manner. I don't need to use Bootstrap because I can just use plain vanilla CSS to write whatever the layout I want. I don't need to add those clumsy BEM classes to manage CSS. It's less busywork. A LOT less, in fact! Everyone says it's easy, so it must be true. Everyone says it helps with large scale collaboration, so it must be true. Everyone says it streamlines the workflow, so it must be true. Everyone says it is simpler and faster to work with than the underlying languages, so it must be true. And, this was me, until I saw how it could be done outside that realm. It now irritates me to see how so many people are missing out on this. Don't feel too bad about it, you were just doing what everyone else does. The people who duped you were duped and deluded themselves, by people who were duped and deluded by people who were duped and deluded by people who when I started doing this stuff refused to abandon 1995 to 1998 style methodology. Yes, it's a big lesson for me NOT to go with the flow so blindly. Even right now, the whole thing utterly shocks me. I see it as an industry-wide, a massive waste of human resources, and I am quite alarmed. I just think of a massive negative implication of wasted bandwidth, costing businesses so much money, and so on. Though again a lot of that is just that the people creating these systems and those so fervently singing their praises didn't know enough HTML or CSS to have any idea just what good code, good practices, or even who to do things properly was. When you lack that fundamental understanding it is so ridiculously easy to believe the claims of your peers or to delude oneself into thinking you found a simpler way. And not to mention how relatively simple it is to write a page of HTML correctly once you learn it. At least it is so in my case. I still say to myself, "What was I doing all these years fiddling with Bootstrap templates and BEM and all that? What a waste!!" Besides, my focus has shifted from starting with appearance to starting with contents and structure. Again, it's a complete paradigm shift. All of a sudden, I find myself cursing at all the typical Bootstrap-ish templates I see all over the Internet. What a colossal waste of bandwidth! I mean, just look at those sites on a smartphone. I used to think it's all good and cool. Now with the contents/structure mindset, It's ridiculous that they all shove "LOOK HOW COOL OUR SITE IS!!" down my bandwidth throat with a massive header image/movie, a bunch of blocks follows with relatively few meaningful things to say. Where are the useful contents!?!? Why do they want to waste so much time with AJAX animation and moving stuff for no practical reasons??? I can't believe I bought into that style.

I found this article which present a compelling case against Sass: https://meiert.com/en/blog/no-css-preprocessors/ His case: I don’t feel the problems CSS preprocessors intend to solve are serious enough to warrant the cost, either, and to me the solution is worse than the problems as well. I want absolute control of my CSS and work directly on it, too, and likewise see exactly what will be sent to the browser before it’s getting minified and compressed. (In this list I don’t care too much that parts of the concerns may be addressed through better tools in the future.) I don’t want to learn and depend on a non-standard syntax to wrap my CSS in, either, neither would I want to learn several syntaxes, and again neither would I want my teams to. I want my source CSS to be deployable at all times, too, and if any build processes fail I equally like to be able to deploy the source CSS as an emergency solution. I don’t want to have to wait for compilation before seeing the results of CSS changes, either. In addition to these points, I could always mirror preprocessor functionality through languages like PHP, just like Bert Bos had brought forth as a main argument against CSS constants. The only exception to me, and there I disagree with Roger, is that we don’t only need but can actually have pretty DRY CSS without preprocessors. Not repeating ourselves should be first nature to us, a part of our craft, and as we can’t yet automate DRYing up CSS it’s on us to keep our style sheets efficient and maintainable. I find it a nice addendum to Jason Knight 's already compelling argument. As for me, I've been practicing grouping selectors as I go. I find it perfectly feasible to skip Sass at this point, at least in my case.

Jason Knight OMG. Another eye-opener. The article made me painfully realize one reality of this whole thing. All these arguments for using visual builders, Sass, BEM, etc. is mostly about what makes CODERS' job "easy" and LAZY, and none of them are about what's right for USERS of the web and doing our job CORRECTLY!!! Worse, all of these things utterly fail to deliver what they promise!! I should think more about what's right for the people who pay me to do the job. Wow. Why didn't I think of THAT? All of a sudden, I realize many of us are so caught up making money out of thin air, and we completely forgot how to think. I mean, sheesh, just looking at my past comments again in light of this article, the whole "let's slap together something, who cares about a few kilobytes, let's brute-force everything!" mentality is now making me feel disgusted. Holy crap, that garbage mentality I spewed all over is also how a lot of so-called experts are advocating, too, since I merely followed them so blindly like a mouth-breather?? Dang.