Looking for web design tips for 2015

I recently came across a roundup with 38 website design tips (https://psdtowp.net/web-design-tips.html) in it (the author asked 38 web designers for it). It is a big list of tips, but I think a lot of the tips are very similar. While reading the tips, I got more questions then answers so my question to you all:

What are your best web design tips for 2015?

TIA!

 

Depends on what you intend to do. If you are looking to do web design, then I suggest you find a good web developer to educate you in what works in practice instead of just looking like art. If you intend to do development then forget all tips from web designers forget that Photoshop exists, and at all cost avoid contamination by staying away from bloat inducing junk lile WP and learn to code thing yourself.

The most screwed up web sites in the world are the result of a web designer being in charge instead of a web developers. The slowest websites in the world are that way because a web designer decided that their "vision" was more important than the user experience so they loaded on enough graphic to sink an
aircraft carrier and refused to hear objections from the web developer who had to figure out how to load 25 mb of art in an acceptable amount of time.

Does it sound like I am down on Web designers? Only when they think sites are about them and their egos and them demostrating whay an artist they are. Web site exist to serve users, and they are only impressed once by the design, after that they are just angry everytime they have to wait more than 3 seconds for it to load.

 

Regarding the recent changes in web design. I'm quite amazed myself xD (been a while out of designing biz). It looks like the trend is still focusing on the "flat design" look. but with greater enhancement in "BIG" text which is eye-popping. 2, one-page theme, you know, 1 horizontal column across the page (called a feature div/seg/orwhatever.) I quite like the new trend, also implementing most of it into my current designs.

 

A LOT of the advice in that link is just idiotic nonsense and the opposite of not just my experience, but common sense. So many of those fools are recommending tools that to be frank just make you work harder or fail to grasp the entire reason HTML and CSS even exist in the first place; LESS, SASS, CSS frameworks, JS frameworks -- it's all bloated nonsense that makes you work harder, not smarter; and to be frank in most cases prevents you from learning not just the underlying technologies but all the good practices that have developed over the past decade and a half.

This post is probably going to be a bit bigger than any of those as I'm going to take the time to actually EXPLAIN what I'm saying; but again I'm one of those people who says the TLDR twitter generation can piss off! It's called literacy, try it!

The biggest thing you should be focusing on is delivering content to users! THAT IS WHY WEBSITES EXIST! The goofy artsy fartsy "form over function" nonsense pissed out by the PSD jockeys and "gee ain't it neat" animated scripttard BS usually just gets in the way of that making pages HARDER to use, harder to digest, and worst of all, painfully slow loading inaccessible disasters.

The most recent change to my "advice" would be the addition of responsive design SIX YEARS AGO. Apart from that, proper design remains what it has always SUPPOSED to have been about, visual accessibility and device neutrality. Simple fact is if you've been paying attention to what we had been being told by the W3C prior to the idiocy known as HTML 5 and the halfwits at the WhatWG sending development practices back to the worst of 1997, MOST of the 'new' concepts are just the old concepts with new names and you would have seen it coming!

VISUAL ACCESSIBILITY
--------------------------------
Learning accessibility norms for your visual design is a MUST, yet sadly something greatly lacking in the skillset of most of the ignorant halfwit PSD jockeys with the giant pair of brass to call their goofy pictures "web design". While guidelines like the WCAG exist, they can be hard to digest but the really important parts can be summarized fairly quickly:

1) Colour Contrasts
This one is simple, does your foreground text color have sufficient contrast to the background color and/or image. Images behind text are often a disaster and should be avoided unless you REALLY know what you are doing. A Gaussian blur of the image can be used to determine a median color, but background-color or background-image meeting the norms involves some relatively simple math based on usability studies that are now approaching three decades old; that most developers are STILL unaware of them despite being in the Windows interface guidelines, MacOS interface guidelines, OS/2 interface guidelines, VGA specification (used to display convert colours to analog monochrome displays) AND the Web Content Accessibility Guidelines is simply mind blowing.

It's all based on luminance in an emissive colourspace, aka YPbPr -- which sadly is not what most paint programs call luminance since they calculate it for reflective (print) since again, most paint programs like Photoshop are meant for PRINT and photo editing, not web content!

The PROPER formula is:
Y = 0.299 * R + 0.587 * G + 0.114 * B

Though some simplify that to
Y = 0.3 * R + 0.59 * G + 0.11 * B

Which is "close enough for government work"

Once you have your foreground and background colors converted using that formula into Luma, you should consider a 50% difference as the minimum; that was the "old" standard -- but with really thin glyphs, LCD subpixel hinting and font smoothing technologies and differences in font renderers that minimum can very quickly increase to 70% or more. YES, this limits your range of brightnesses, but it also means your text might actually be *SHOCK* legible. An extra bonus is not only does this help normally sighted people read your text, it's near impossible following this to end up with something the colour blind can't read either!

For example, ever notice that pure red on pure blue text is pretty much an eyesore? The math supports this!

#FF0000 red == 255,0,0 == Y 76
#0000FF blue == 0,0,255 == Y 29

Difference is 47 out of 255, aka only 18% of the spectrum -- OF COURSE it's illegible!

Pretty much you want a difference of 128 as a minimum, and if you use a really thin glyph font or really small sizes, that number can climb as high as a 192 ideal.

2) Dynamic Font Sizes

To put this as simply as possible, pixel metric fonts are an accessibility mess that do not auto scale to OS or browser preferences (whichever the browser is obeying at the moment). While 16px is the most common default, it is not the ONLY default as the user can change the default font size in the browser, and some browsers can inherit it from the OS. My main laptop? I've got that set to 1EM = 20px. My media center? 1EM = 24px!

Using % or EM's for font-size means the fonts will automatically enlarge or shrink to the user preference -- that's why the WCAG says to use them, why your layout should be able to compensate/adjust to said changes, and why generally speaking fonts declared in PX should be restricted to cases where it's non-content elements or underneath complex image interactions like gilder-levin.

*side note, WHENEVER you change font-size redeclare your line-height, you CANNOT trust it to inherit properly. SOME people will claim if you omit a metric and just say "line-height:1.5" instead of "1.5EM" or "150%" it will inherit -- this is inconsistent across browsers and 100% grade A farm fresh manure no matter how many so called "experts" claim otherwise! I also like taller line-heights of 150% or more as they too can help legibility -- a LOT of sites using 120% or less have major legibility issues!

3) Semi-fluid elastic design

Semi-fluid design is easy; you let the layout expand and contract in size automatically with a maximum width set so that long lines of text don't get hard to follow. Since the fonts can change size WITHOUT zoom (see dynamic font sizes above) and the reason to do this is for long line behavior, your maximum width should likely be set in EM's.

Fixed width layouts are universally inaccessible trash, and anyone telling you otherwise doesn't know enough about web design or accessibility to be flapping their gums on the subject.

Failing to follow the above three combined USED to be called "the trifecta of FAIL" at web development back when people gave a flying purple fish about accessibility, the laugh is they are ALL stepping stones towards doing this next one properly:

4) Responsive Layout

This is just a big fancy name for the next logical step after all the other bits of design; done at it's simplest it's simply adding or removing columns and adjusting presentation so as to best fit the display. If you've done the three previous points, practicing other good concepts like semantic markup (a sick euphemism for "using HTML properly"), separation of presentation from content, media targets and progressive enhancement (which I'll cover in the next section) making a website responsive shouldn't take more than ten to twenty minutes and MAYBE 2k of CSS.

The laugh being to avoid writing that 2k of CSS most people these days seem to double the size of their markup with presentational classes so it's "easier" to use some ridiculous 100k or more "framework" bullshit. I still will never understand how using more code, adding more to learn, writing more code yourself as a result, and pissing away concepts like progressive enhancement is "easier". That's some high octane kool-aid they're pushing right there.

You do all those things, for VISUAL / screen media users you are pretty much golden; the thing is, those are NOT the only possible users or visitors to the site (yes there's a difference, don't forget search) which brings us to:

... bah, silly little 30k post size limit... to be continued.

 

... continued

DEVICE NEUTRALITY
--------------------------------
For all the talk about "mobile this", "mobile that" and "mobile some other damned thing" it's just the latest flavor of what HTML is SUPPOSED to have been about from the bloody start! That being device neutrality.

When Tim Berners Lee created HTML, it was to deal with the problem of sending documents (content) to a variety of devices of wildly differing capabilities -- text only terminals, braille, teletype, home computers with text capabilities ranging from 21x22 color to 132x72 monochrome, home and business computers with graphics ranging from 256x192 to the 1152x736 of the NeXT workstation he happened to be working at. Nothing like today at all where all devices have screens are the exact same size and resolution. :/

These documents would also be able to refer not only to themselves internally, but to other documents on any file resource local or over a network available to the system, it was thus the Hypertext Markup Language was born.

Markup languages were nothing new; HTML itself being based on SGML. What was new about it was predefined tags that had meanings; said meanings being what elements would be in a professionally written document... paragraphs for actual paragraphs of flow text, headings and rules to divide content into subsections; lists do define bullet points be they ordered or unordered, even <B> and <I> have a semantic meaning based on WHY something would be bold or italic (proper title and publication title respectively) based on professional writing norms. (hence why STRONG and EM are NOT substitutes for B and I, no matter how many illiterate fools claim otherwise).

The whole idea was to say what things ARE or what they WOULD BE based on how professional writers well... write. Logical document structure, leveled headings and horizontal rules to declare beginning and ends of subsections, these are all concepts people writing whitepapers, scientific papers, journal articles or even something as simple as a essay for a junior high class should be familiar with. Though with most people coming out of high school these days with the equivalent of what was considered a 4th grade education when I was in school...

It was then the duty of the "user agent", what today we call a browser, to determine how to best convey that information within the capabilities of the device it was trying to be accessed from. Some devices could show color but not bold or italic, some devices could only show fonts at a uniform size -- all that had to be accounted for.

The whole concept today is called "semantic markup" -- but as I've said a lot lately that's more a sick euphemism for "using HTML properly", likely used so as not to offend the halfwits, morons and fools who just sleaze out their markup any old way. (like 99%+ of the scam artists vomiting up off the shelf "templates")

It wasn't until the web really started gaining traction and two giants -- Netscape and Microsoft -- went to war that we really started getting away from that. The question slowly became not "how am I going to use this to convey my content to as many people in a meaningful manner" but "How pretty can I make it on the screen I happen to be in front of right now". This became known as "the browser wars" and led to some of the WORST things possible in terms of "semantic" practices and accessibility, leading HTML away from the very reason it even existed.

This led to the disaster known as HTML 3.2 followed quickly by a bunch of vendor proprietary crap -- some of which was accepted into HTML 4 transitional. Both are an accessibility nightmare and why the REAL HTML 4 -- aka STRICT -- was created; it was basically an attempt to drag everyone kicking and screaming BACK to what HTML was actually for so that CSS and JS could handle the rest. This would give us back our accessibility and ease of access while letting the "gee ain't it neat" artsy crap be slathered on top of that base. More so by moving presentation out of the markup designers could customize the presentation to DIFFERENT devices like print, aural, handheld, etc, etc.. This would also allow better caching models to be introduced since presentation common to multiple pages can be cached across pages or reloads of the same page, and pre-caching of sub-page appearances could be handled on first-load.

Transitional quite literally meant "in transition from 1997 to 1998 coding practices" -- a polite way of saying that old crappy browser-wars era sites could switch to transitional to use some of the stuff introduced in HTML 4, while all new sites would be written using STRICT using all the other important improvements 4 introduced. STRICT also was about simplifying the specification by the removal of redundancies and elements that just caused accessibility headaches.

So naturally everyone went and learned to use HTML properly with STRICT, started using semantic markup, and worried about accessibility and the ability to convey the content on as many devices and to as many users as possible? NOPE -- people to this day continue to sleaze out bloated buggy inaccessible train wrecks of HTML 3.2 and proprietary tags with either 4 tranny or 5 lip-service on it as a doctype.

In fact, for the most part the majority of developers continued to stuff their heads up 1997's backside, refusing to even acknowledge the concepts of accessibility, separation of presentation from content, etc, etc... even when they used CSS they did so hap-hazardly putting it in the markup (I still say the <STYLE> tag should be made obsolete and STYLE="" attribute deprecated).

This of course led to the TRAIN WRECK that is HTML 5, created not by the W3C but by a group called the WhatWG, who instead of bothering to embrace STRICT and grasp it's concepts, instead decided to make a specification based on what people WERE doing instead of what people SHOULD be doing. That's why it introduces all sorts of redundancies (many of which were EXACTLY the type of thing STRICT was trying to get rid of) and has a number of elements that seem more presentational than semantic in intent.

That's why MOST of what people vomit up with a HTML 5 doctype on it is nothing more than HTML 3.2 and all the proprietary crap we were supposed to stop using 17 years ago legitimized in a "people aren't bothering to do things properly, so oh well" sort of way. It's the W3C taking WhatWG's BS, throwing up their hands and walking away from trying to ACTUALLY make things better. That's why whenever someone calls HTML 5 "the future" my gut reaction is "REALLY? Looks like the worst of 1997 to me!"

... which is also why an advice you'll hear from a lot of developers is to write in HTML 4 STRICT or XHTML 1.0 STRICT, and if you HAVE to use some of the HTML 5 garbage because it's shoved down your throat (AUDIO, VIDEO) by crApple being jackasses to their own users, or the handful of things that ACTUALLY serve a legitimate purpose (MANIFEST) put the 5 doctype on it at the last moment. Due to browser makers using vendor lock-in through the pointlessly redundant AUDIO and VIDEO tags you often end up forced into using them.

There's a reason EMBED and BGSOUND wasn't accepted into STRICT, and that APPLET and IFRAME were deprecated - and that early accounts of the original "next generation" HTML had IMG on the chopping block for being redundant and leaving developers at the will of what browser makers just feel like implementing. Go HTML 5 for creating vendor lock-in for the browser makers and re-introducing old redundancies browser-wars style!

That original intent of HTML and the attempt to recreate that intent with STRICT is the thing I'm trying to drive home here -- semantics and separation of presentation from content. Your markup (even your id's and classes when possible) should say what things ARE, NOT what they look like. You do this and it becomes easy to customize the appearance for not just the standard MEDIA targets (screen, projection, tv, print, aural, handheld, teletype) if desired, but also to customize things using media queries. IT also provides something equally important -- graceful degradation since done properly you are "progressively enhancing" the page.

Progressive enhancement is one of the cornerstones of accessible design, yet somehow it's something a LOT of alleged "names" in the industry are now pissing on from orbit either out of ignorance or just plain willful spite; they don't want to hear that they've been doing things wrong for nearly twenty years, and people new to the industry don't want to hear they've spent a year or more having those same jackasses blowing smoke up their backside with outmoded outdated halfwit practices.

The concept is simple, you start out with the simplest part of the page, and then slowly add things to it to make it more useful to visitors and/or customize it for specific device capabilities. That's device neutrality in a nutshell -- no matter what the device your one core document can be crafted to fit it! That way should any of those customizations or fancy bits of enhancement fail or be unavailable, you still have a page that is useul to visitors REGARDLESS of device.

Hence why my method for design is as follows:

1) Take the content or a reasonable facsimile of future content and put it into a flat text editor as if HTML never even existed.

2) mark up that content saying what things ARE. Since that's semantics you would NOT be adding semantically neutral containers like DIV or SPAN at this point since those are hooks for style without saying specifically what that style IS. This gives you your non-screen media and non-CSS capable baseline -- the ideal both in terms of what search engines see and accessible design. Since numbered headings indicate sections and their subsections, and horizontal rules indicate section changes where a heading is unwanted or unwarranted this means most of the allegedly semantic HTML 5 tags (like SECTION, ARTICLE, ASIDE and FOOTER) really serve no legitimate purpose -- document order and those headings/rules should MORE than convey that!

ANY images used at this point should be CONTENT and NOT presentation. That means in most cases things like site logo's should be omitted as they are usually a presentational affectation of the site name. Pretty much if it's not actually a content image, it has NO damned business in a IMG or OBJECT tag.

3) Create your CSS layoutS (yes, PLURAL) for the different media targets you want to support AND any media queries needed to adjust your visual layouts for different device sizes and resolutions.

THIS is the point at which you can add DIV and SPAN to the markup preferably using classes and ID's that again, say what things ARE and NOT the appearance you are adding. This is due to the fact that just because it's "red" or "eightColumns" on one layout doesn't mean they are on ALL your different layouts for the different media targets.

Since up above we mentioned using dynamic fonts, as with the max-width for semi-fluid design it helps to make as many of your media query breakpoints based on EM's. The only real reason to use PX measurements in your breakpoints is for things like logo's and other image based content to either adjust or remove them.

A good rule of thumb is to try and have ONE monolithic stylesheet for each media type unless you are REALLY sure that second sheet is on a page accessed less frequently. TYPICALLY the amount of CSS unique to a sub-page isn't worth the time of the extra handshake, and putting it into the main sheet means less handshakes and a chance to pre-cache subpage appearance -- REALLY handy on things like forums.

In that same way, if you are using the <STYLE> tag in your markup, you've completely missed the point of CSS -- keeping what things look like out of the markup. There ARE a handful of corner cases where the STYLE attribute can be used to enhance conveying information (tag clouds, progress bars and statistics) but for the most part if you are using that, you've completely missed the point of CSS. Likewise if you are using media="all" or not declaring the MEDIA attribute on your LINK, you've completely missed the point of CSS.

I know that flies in the face of recent changes to Google's "pagespeed insights" but to be brutally frank over the past year or two that's been slowly transformed from good practices and actual advice on making sites faster to trying to get you to dick around with cache settings that don't do anything leaving you blindly hoping that throwing a CDN at crappy code and hundreds of separate files will actually fix things -- you'd almost think they were shilling for CDN sellers or offering a "pagespeed service" that is more lie than fact.

The latter also pissing all over accessibility and speed, then they have the giant set of brass to call it "faster"

4) then and only then hang any extra presentational images (if any) on the markup. The use of CSS3 can greatly reduce the need for a whole lot of that. Things like logo's, symbols or sprites

5) then and only then further enhance the page with things like JavaScript -- and at that point I HIGHLY recommend that you remember the "unwritten rule of JavaScript" - If you can't make the page fully functional without scripting FIRST, you likely have zero business adding JavaScript to it!"

That's what progressive enhancement IS, slowly adding bits to the page so that when things are missing the page is still usable. It might not be pretty, it might not be perfect, but it's still USEFUL. Images off? Page still works. CSS off? Page still delivers content to users. Scripting disabled or blocked? Page is still useful and usable. Different screen sizes and resolutions? Page adjusts so as to best show that content. That's called graceful degradation and is why "responsive layout" and "mobile design" are simply that next logical step in accessible design.

If you can't do that, then you likely have NO damned business making websites in the first place! Sadly that describes 99.999999% of the scam artists preying on the ignorance of nubes at whorehouses like ThemeForest and TemplateMonster, and the halfwits, morons and fools relying on nonsense like "frameworks" or letting CMS systems crap all over the output.

See the garbage turdpress vomits up like this:

<body class="home blog">
    <div id="header-wrapper">
        <div id="header">
            <h1><a href="https://wp-themes.com">Theme Preview</a></h1>
                            <h2>Previewing Another WordPress Blog</h2>
                    </div>
    </div>
    <div id="access-wrapper">
        <div id="access" role="navigation">
            <div class="menu"><ul><li class="page_item page-item-2"><a href="https://wp-themes.com/?page_id=2">About</a></li><li class="page_item page-item-46 page_item_has_children"><a href="https://wp-themes.com/?page_id=46">Parent Page</a><ul class='children'><li class="page_item page-item-49"><a href="https://wp-themes.com/?page_id=49">Sub-page</a></li></ul></li></ul></div>
            <div class="clearfix"></div>
        </div>
    </div>

Code (markup):

or the absolute idiotic halfwit nonsense things like Bootcrap suggests using:

<body class="bs-docs-home">
    <a id="skippy" class="sr-only sr-only-focusable" href="#content"><div class="container"><span class="skiplink-text">Skip to main content</span></div></a>

    <!-- Docs master nav -->
    <header class="navbar navbar-static-top bs-docs-nav" id="top" role="banner">
  <div class="container">
    <div class="navbar-header">
      <button class="navbar-toggle collapsed" type="button" data-toggle="collapse" data-target=".bs-navbar-collapse">
        <span class="sr-only">Toggle navigation</span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      </button>
      <a href="../" class="navbar-brand">Bootstrap</a>
    </div>
    <nav class="collapse navbar-collapse bs-navbar-collapse">

Code (markup):

If you don't know what's wrong with those, you probably need to do the world a favor, back the *** away from the keyboard and not bother coming back until you have something resembling a clue!

Hence why another piece of advice would be to STAY THE HELL AWAY FROM FRAMEWORKS -- they are ALL universally bloated rubbish used by people not qualified to be making websites in the first place; they may serve a purpose in a handful of cases when making web crApplets, but on normal websites all they do is piss all over the markup, bloat out the page making them slower, and in general make more work, not less.

The same goes for the "preprocessor" nonsense like LESS and SASS -- at BEST they are crutches for people who don't know enough about HTML or CSS to be making websites, at worst they actively promote broken bloated coding practices. The only way you'd see "savings" from using them is if you are using two or three times as much CSS to do things as you should in the first place, either out of ignorance or a failure to grasp what the "cascading" part of "cascading style sheets" means.

Much of that attitude comes from doing things like practicing size targets. Statistically speaking one should have a pretty good idea how big the code for a page should be.

Markup for example is easy, and this is overly generous:

Target HTML file size = 1024 bytes + plaintext size * 1.5 + 128 bytes per IMG tag + 128 bytes per form + 64 bytes per INPUT/TEXTAREA/OPTION + 256 bytes per OBJECT, AUDIO or VIDEO

If your site exceeds the result by a significant amount, it's poorly/ineptly coded. You also have the "code to content ratio" or CtC -- which is simply the size of your markup compared to your plaintext content. It is SHOCKING how many people will sleaze out dozens if not hundreds of K of code doing 10 to 20k's job, resulting in CtC's of 10:1 or more. THEN the dipshits vomiting up their markup that way go "but what's wrong with that?" and start coming up with lame excuses to justify their bloated trash.

That same way, realistically for even the largest website there is NO legitimate reason to have more than around 48k of CSS uncompressed -- realistically the majority of over-glorified blogs people vomit up blindly hoping for success with have no need of more than half that; which is another stroke against off the shelf CSS frameworks like YUI, blueprint or bootstrap since they start out at a ridiculous 100k or more to then have the developer write the same or even more code with bloated markup. Herpafreakingderp!

It also helps to try and have a realistic content size limit for "normal pages" -- generally my "ideal target size" is 72k in a dozen or less files not counting content images; that's HTML + CSS + SCRIPTS. Counting content images I aim for double that. I know in this age of people sleazing out megabytes of scripttardery for nothing and hundreds of K of CSS for Christmas only knows what those numbers sound low -- but generally speaking anything USEFUL on a site can be implemented within those limits, anything that can't fit those limits probably doesn't belong on a website in the first place!

Certainly specific types of pages like galleries will far exceed that once content is in there, but for normal pages on a site there is little if any excuse for more than that other than developer ineptitude or artsy fartsy bull that is NO actual legitimate use to visitors other than making sites harder to use.

A final bit of advice goes with some of what some folks said on that site -- so not everything there was rubbish. That advice being keep it SIMPLE.

Even when they are a coding disaster or have major accessibility failings, you can learn a LOT from the biggest success stories of the Internet. Amazon, e-bay, google, facebook, twitter -- do any of these actually look like they have some artist spanking it on the screen in Photoshop and calling it "design" involved in their process? Hell, you want to make your typical "designer" recoil in horror, ask their opinion of CraigsList. These pages focus on what's important -- their content! They don't screw around with a bunch of extra presentational nonsense to stroke the artists... ego... let's say ego, and instead focus on delivering their content to users. You could do far, FAR worse than to follow their example.

There's a reason the really fancy artsy-fartsy "design" type sites usually fall into one of four categories:

1) businesses run by people who don't know enough to be making decisions about having a website. These run the gamut from small business owners who got scammed, to big brick and mortars for whom a web presence is an afterthought.

2) Template whorehouses trying to dupe the ignorant into wasting money on artsy stuff because it's usually easier to scam nubes with something pretty than it is with actual functionality.

3) The websites of artists trying to show off their L33t skills. Sadly if you know anything about accessibility it also showcases their ignorance and ineptitude.

4) Nube websites thrown together quickly out of ignorance, apathy and wishful thinking, the end result being akin to the Worst Website Ever

There are rules and guidelines to follow, an intent stemming from professional writing for accessible delivery of content and clear meaning. IGNORE THEM AT YOUR OWN RISK!

I know that's a lot to digest, but hey, you asked -- and as always the TLDR crowd can piss right off; particularly since most of them will blindly disagree without actually reading it much less comprehending the slightest part of it - since for them and their immoral snake oil sleazeball scam artist practices I may as well be speaking an alien language.

In other words, it's called literacy. People should try it, it's nice!

 

Bloated sites are always a dead giveaway not when pages load too slow, but when my CPU fan kicks in.

I suspect (hope) we'll see the pendulum swing back a bit. Bootstrap was positioned at least to play to that aesthetic, no?

 

That's a great indicator of either too many DOM elements, too much scripting, or a healthy does of both. In the age of highly efficient JS engines like V8 and multi-core multi-ghz processors being the norm, something as ridiculously simple as a website causing CPU spikes, memory spikes and triggering things like laptop cooling fans are indeed a great indicator of developer ineptitude.

Though it raises a good point -- Never trust that if a site is fast for me that it's fast for everyone, or that if a site is slow for me it's slow for everyone. You'll see people making websites make that mistake ALL the time; "But it's fast for me!" -- well whoopedee freaking-doo for you!

ALWAYS go with the numbers; total filesizes and more importantly, total number of separate files. The less you have the better. One should ALWAYS remember that "real world" the average handshake overhead REGARDLESS of connection speed for each file past the first 8 is 200ms, and worst case scenario could be a second or more per file. Sure, if you are sitting on top of your hosting it can be as little as 30ms for you, but that doesn't mean it's that way for everyone.

It's part of why I try to stick to a half dozen or less files for HTML+CSS+SCRIPTS, and two dozen or less once content images are involved. That way the average first-load handshaking delay is reduced to 4 seconds or less, and worst case of 20 seconds; as opposed to people using 100 separate files thanks to endless pointless separate files seeing averages of 20 seconds and worst case of two minutes or more.

Of course, so many people now just try to throw things like CDN's at that as if adding another domain lookup and more complex structures will let them just continue to sleaze things out any old way instead of fixing what's actually wrong; that "change" in how Google's "pagespeed insights" works, and the ridiculous bloated train wreck of ineptitude they call "pagespeed service" being stunning examples of that particular bit of idiocy in action. (hence why most of my sites see zero benefit or even load slower if I were to follow their advice!)

The laugh then being their flailing about helplessly using nonsense like minification to just sweep their bad coding practices under the rug; minification should be a last resort, not the first thing to try. On a well written website minification shouldn't even save you more than 1 or 2k, a relative non-issue. If it's saving you more than that you're probably doing something wrong. (like using some idiotic fat bloated library crap).

If by playing to that you mean adding such ridiculous pointless idiotic bloat and bad practices it scares people back into writing HTML and CSS properly, then maybe. There's a reason I keep telling people to find a stick to scrape the bootcrap off with before they smear it all over their website's carpets. I cannot fathom how ANYONE could be dumb enough to see any merit in it's use other than the traditional reasons of -- again to borrow from Ike -- Apathy, ignorance and wishful thinking.

Though lately it seems those three things have become the driving force in "modern" development. NEVER underestimate the power and broad mass appeal of apathy, ignorance and wishful thinking; see how nonsense like "faith" continues to even exist.

 

Actually Bootstrap is designed to appeal to wanabes who are too lazy to learn how to do things right.

 

I actually disagree on the LAZY part; why? because it's so mouth-breathingly idiotic a bunch of halfwit nonsense it actually advocates writing markup like this:

<div class="col-xs-12 col-sm-8 col-md-8 col-xs-offset-4 col-sm-offset-2 col-md-offset-2">

Code (markup):

It's using more code in the form of a massive library to make you write more markup using presentational classes alongside even more CSS of your own and scripttardery to make things even more pointlessly complex. That's why people end up vomting up dozens of K of markup to do 10k's job, hundreds of K of CSS to do 16k's job, and hundreds of K of scripttardery to do 0k's job.

Using more code, writing more code, to make it harder to create, harder to maintain, harder to update, harder to fix, and to not even have it ACTUALLY deliver an accessible layout is not "easier" -- it's making more work for no good reason. Extra work for no good reason isn't lazy, quite the opposite in fact!

Though the part about people who don't want to learn to do anything doesn't make much sense either given that one still has to learn HTML and CSS to even use it, and then learn bootcrap as well... making it even more ridiculous.

Of course, actually understanding HTML and CSS is all it takes to turn nutjob crazy bs like bootcrap, YUI, blueprint or any of the rest of such asshattery into a laughing stock; sadly that seems to be sorely lacking.

ANYONE calling these HTML/CSS/JS frameworks "simpler", or "easier", or "faster" doesn't know enough about HTML and CSS to be flapping their gums on the subject.

 

I used to follow Deathshadow's advice for the past few years, he influenced me a lot in how I write and organize my code, but apparently, it started to feel like comparing cars; classic vs modern. Shares the same fundamentals, but when its time to upgrade, you should. It's like life, as you grow older you mature and that old car, you sell it for a new one that's better, faster.

His concept of a website and how it works is basically basic stuff, but computers are getting faster, browsers are getting complex. Its either we stick to where we are, or we move forward.

These frameworks exist because there are developers out there working on something and they found out that their code can be refactored and reused, and figured that they should share it with others. When you're working on large projects, this make sense A LOT, but for beginners, you should at least get a grasp of the tech behind all this.

Each piece of code we write will go through series of tests and matures. That's why we don't reinvent the wheel. We improve the wheel. The new code we write, is not the same as codes that has been reviewed, used, and tested by many. All the security issues, bugs, etc has been experienced by the mature code that our new code hasn't.

 

Thanks a lot for your extensive answer(s). I never thought I would learn so much from one question! You're epic!