Consider all the things front end frameworks do that you shouldn't. Like use endless pointless DIV for nothing. Like slop endless pointless PRESENTATIONAL classes onto things. Like break the separation of concerns. Like using JavaScript to do things that HTML and CSS can do without scripting. Like using JavaScript in a manner -- such as CSR -- that doesn't gracefully degrade and tells users who have scripting blocked/disabled/unavailable to go suck an egg. Like failing to realize there is more to actual design than what it looks like on screen media. Like using innerHTML methodology and onevent attributes like it's 1998 in violation of good practices.
You take all those things, and you don't do them.
... and if you want simple maintainable code, it's harder to do using frameworks. ALL the claims of "easier' or 'simpler" or "more productive" about these dumbass systems that border upon outright SCAMS hold water like a steel sieve. I've NEVER seen a front-end framework -- be it for HTML/CSS or for JavaScript -- that didn't create more problems than the solve, and result in two to ten times the HTML needed to do the job, gibberish nonsemantic HTML, as much if not more CSS/Scripting of your own than you'd have written without it...
... which if you're writing more HTML and as much CSS or JS as you should have without it, it's not simple and maintainable. That's what I call bullshit.
*Ohs noes, he usededed teh harhs wurdz aggins"
And one of those separations is the simple fact that NONE of your HTML -- be it tags, classes, or id's -- has ANY business saying what things look like. HTML is for saying what things are or would be for grammatical and syntactical reasons.
That means H1..H6 and HR fanning out tree-like to create the base alternative navigation structure. It means P is for paragraphs not just "this is text" and sure as the hell not for lone IMG or form elements. It means IMG is for CONTENT images not presentation. It means B is for legal entities/parties and proper names, I is for things like book titles that are not being CITEd, it means EM is for when text has EMphasis, it means STRONG is for "More emphasis".
As a dearly departed friend (and something of a legend on various development forums) wrote a decade ago:
If you choose your markup based on what you want things to look like, you're choosing all the wrong tags for all the wrong reasons.
H1..H6 do not mean "fonts in different weights and sizes". An H1 -- unless you use HTML 5's idiotic SECTION tag -- is THE heading (singular) that everything on THE page (singular) is a subsection of. An H2 is the start of a subsection of that initial H1 with the first H2 indicating the start of the 'main' content. An H3 is the start of a subsection of the section started by the H3 before it. An H4 is the start of a subsection of the H3 preceding it. Care to guess what H5 and H6's purpose is? An HR means "a change in section or topic where a heading is unwanted or unwarranted. under HTML 5 rules it's considered paragraph level, traditional rules it's either the depth of the heading preceding it, or H2 depth if the last one on the page.
That's why they have DEPTHS, and why starting a page with a H5 is gibberish. That's why dropping to H5 or H6 depth without any H4 or H3 on the page is incompetent ignorant nonsense. That's why pairing numbered headings together for "title and tagname" such as the classic H1+H2 we always see -- and HTML 5's dumbass now defunct HGROUP -- is equally mentally enfeebled and completely misses the point of why headings have numbers.
... and part of why on the whole I do not believe the WhatWG had embraced the intent of HTML or the concepts of HTML 4 Strict sufficiently to have been entrusted with creating its successor. HGROUP being obvious proof of it, but with the above concepts lifted straight from professional writing, MOST of the new "structural" tags are nonsense. HEADER, FOOTER, MAIN, ARTICLE, ASIDE, NAV -- IMHO they are pointless redundancies
Same goes for garbage like the STYLE tag and the STYLE="" attribute. If you use the STYLE tag AT ALL you're doing it all wrong, since you just missed a caching opportunity and it's not like you shouldn't have an external stylesheet. With STYLE="" you have no graceful degrading method for media targets, might be applying code that's gibberish or inapplicable for specific media targets,
Hence why if you aren't saying MEDIA="" on your stylesheet link, or if you are but sending MEDIA="ALL" you've failed spectacularly to grasp the point of CSS. When I see no media attribute or MEDIA="ALL" I automatically assume the developer doesn't know enough about HTML or CSS to be using web technologies.
You want simple, small, accessibile results? Progressive enhancement with separation of concerns, that way what you do gracefully degrades when your fancy bits go AWOL for whatever reason.
Assuming a normal website, as I've said many many times you start out making the base template before you even THINK about server-side.
Queue broken record.
1) Take your content or a reasonable facsimile of future content and put it into a flat text editor. You then organize it into a logical document structure meeting professional writing norms as if HTML, CSS, and JavaScript do not even EXIST yet.
2) Mark that content up semanticall saying what things ARE, and NOT what you want it to look like. Since this is the semantic stage DIV, SPAN, and classes have no business in your code at this point.
3) Bend that markup to your will, creating first of many layouts with CSS, adding DIV, SPAN, classes, and ID's as appropriate. I suggest starting with the legacy screen media desktop layout since that's what you can't target with media queries to make responsive. The whole concept of "mobile first" being utterly back-assward since you CAN target modern mobile with media queries, that's what it's FOR. Starting out with mobile pretty much ends up a case of "well now what?!?" when it comes to targeting desktop.
Your base layout should be
A) elastic (built with EM, not PX)
B) semi-fluid (having a max-width to prevent long lines from being hard to follow whist shrinking to fit smaller displays. PERHAPS with
C) Meet accessibility norms like legible colour contrasts.
4) then make it responsive adding more layouts, stripping off columns as needed. You might even consider adding columns for larger 4k displays as well.
5) Enhance the already working page with JavaScript as desired, but really keeping it in your pants as much as possible since scripting CAN lead you down the road of WCAG violations.
This way, if JS fails, if CSS fails/inapplicable, even if HTML itself gets stripped from it, the resultant page still delivers its content in a useful manner.
Now, mind you that's for webSITES. Web Applications can operate under different rules, but be EXTREMELY leery of diving for a web app as the answer to everything just because they're hot and trendy right now.
Web apps are INHERENTLY inaccessible, and violating accessibility norms can land you in COURT with fines and civil lawsuits -- so you HAVE to ask if what the application is doing can be:
1) done as a static website built with SSR
2) is something that cannot be done as anything but a web app
3) actually provides benefits to users that a static site would not.
Far, FAR too many websites right now are diving for 100% CSR solutions and in the process telling users to go plow themselves. The pathetic joke of it all being that they've been duped into thinking that wasting a hundred k of markup, half a megabyte of CSS, and a megabyte or more of JavaScript all to deliver 5k or less of plaintext in a layout that doesn't even warrant the presence of more than 48k of CSS and no JS, was somehow magically resulting in a "faster" loading website.
MAYBE if such developers weren't vomiting up 100k of markup to do 16k or less' job and maintained separation of concerns to leverage caching models, they wouldn't be diving for the CSR BLOAT and running around with this dumbass mentality that somehow "buh pageloads arr teh evilz".
Just look at Hashnode itself, I know a number of Dev's who'd like a place like this, but as CSR only they'll tell you where to shove it having ZERO interest in even visiting this site.
The pathetic part being you can often make pages that load faster with subpages that load even faster than that first-load if you just bothered practicing separation of presentation from content!
it's also why I suggest practicing size targets. I have NEVER seen a website that in terms of what it was delivering for content or even design (or at least the positive aspects of its design and not the goofy bloat that should be axed) that warranted the use of more than 48k of CSS and 128k of JavaScript. NOT counting things like social media plugins or scripted commenting systems.
Just like there is rarely a need for the massive bloated trash people vomit up and have the unmitigated GALL to call HTML. There's a formula I use to determine how big the HTML for a website should be:
. Expected HTML size in bytes = 2048 +
. plaintext * 1.5 +
. content media elements * 256 +
. form elements * 128 +
. anchors * 128
If your page exceeds the result of that calculation it probably has problems. If it exceeds it by more than double, it is incompetently slopped together TRASH where in all likelihood the developer has ZERO damned business writing a single line of HTML.
You want simple and maintainable? Kick your inner artsy-fartsy type in the groin, bend your inner "buh muh JavaScriptz" fanboy over the table telling them to squeal like Ned Beatty, and stick to clean, simple, useful, accessible development practices.
All the things these bloated, ignorant, incompetent, half-witted, dumbass frameworks made by people who CLEARLY have zero business doing a blasted thing in HTML or CSS fail to provide.
Because again, as I always say if you don't know what's wrong with code like this: (lifted straight from a bootcrap example)
<body>
<header>
<div class="collapse bg-dark" id="navbarHeader">
<div class="container">
<div class="row">
<div class="col-sm-8 col-md-7 py-4">
<h4 class="text-white">About</h4>
<p class="text-muted">Add some information about the album below, the author, or any other background context. Make it a few sentences long so folks can pick up some informative tidbits. Then, link them off to some social networking sites or contact information.</p>
</div>
<div class="col-sm-4 offset-md-1 py-4">
<h4 class="text-white">Contact</h4>
<ul class="list-unstyled">
<li><a href="#" class="text-white">Follow on Twitter</a></li>
<li><a href="#" class="text-white">Like on Facebook</a></li>
<li><a href="#" class="text-white">Email me</a></li>
</ul>
</div>
</div>
</div>
</div>
<div class="navbar navbar-dark bg-dark box-shadow">
<div class="container d-flex justify-content-between">
<a href="#" class="navbar-brand d-flex align-items-center">
You don't know the first blasted thing about HTML or CSS. The classes use ALONE reeks of failing to grasp the point of it all, since if you're going to use presentational classes like "text-white", "list-unstyled", "bg-dark", "box-shadow", and "align-items-center' you might as well go back to writing HTML 3.2 with no CSS, using all those CENTER/FONT tags, ALIGN, BGCOLOR, BORDER attributes, and tables for layout that it is painfully obvious the fans of these systems so clearly miss!
Such coding methodology pisses on the entire past two decades of progress, pitching the entire original intent of HTML 2 and HTML 4 Strict in the trash. It REEKS of the broken, inaccessible, garbage HTML 3.2 / browser wars mentality and techniques.
Though again this is hardly a shock with most developers never having embraced HTML 4 Strict and instead spending a decade and a half vomiting up HTML 3.2 with the 4 tranny doctype slopping around atop it. Now they just wrap 5's lip-service doctype around the same nonsensical broken methodology and get to pat each-other on the back over how "modern" they are.
BARF.
INHERENTLY what HTML/CSS frameworks do, and how they go about doing it, are the antithesis of good practices and accessible developement -- and JUST LIKE HTML 3.2 AND THE BROWSER WARS PROPRIETARY STUFF violates the entire reason TBL even created HTML in the first place, what HTML 4 Strict was trying to drag us back to, and the entire reason CSS is (or is supposed to be) a separate specification from HTML!
But tell me again how it provides "scalability", or "maintainability", or "makes you more productive". If you have even the slightest hint of properly understanding HTML, CSS, and JavaScript the claims made about these frameworks should be setting off your BS alarm so hard it can be heard in the vacuum of space!
For people who know nothing of HTML and CSS, BY people who know nothing of HTML and CSS is not a plan for success; no matter how many fools mindlessly parrot the propaganda and praises. Nor is writing two to ten times the code making your life any easier!
Some links to articles by me that elaborate on everything I just said:
cutcodedown.com/article/HTML_CSS_and_JS_frameworks
cutcodedown.com/article/minimalist_semantic_markup
cutcodedown.com/article/whats_wrong_with_YOUR_web…