Should I still use jQuery with HTML5 in 2019?

I came across an article by a developer discussing why he still uses jQuery in 2019 despite the recent trend of going toward vanilla JS in enhancing an HTML document. I am wondering whether he has a good point in his argument. Here are some highlights of his assertions:

---
Many people advocate "just use vanilla JavaScript, you don't need jQuery," but many things we don't need are nonetheless nice to have.

Pages like You might not need jQuery to try to sell the idea that it's easy to ditch jQuery, but it doesn't make sense to replace one line of trivial jQuery code with ten lines of vanilla JS code which takes far more time to write.

Much of the JavaScript API – especially the DOM API – offends his sense of aesthetics. One example is:

el.insertAdjacentElement('afterend', other) undoubtedly works, but$(el).after(other) is actually palatable. He doesn't like how the $() function looks, but he thinks it's "massively better" than what the DOM gives us.

He argues that vanilla JS still need helper functions for various everyday tasks, and browser compatibility is still an issue, both of which jQuery addresses nicely according to him.

He thinks jQuery's file size is trivial; the default build is 30K minified/compressed, a custom build without ajax and uncommon stuff 23K, and a build which uses querySelector instead of SizzleJS is 17K. Both the original 30K and optimized 17K seem pretty acceptable to him for many purposes.
---

What do you think? Does he have a point? Or should I ignore him and learn vanilla JS?

 

I have always wondered where the MYTH of it "speeding up development" came from. It's a bit like the CLAIMS of it being somehow "easier" that are utterly unsupported by the results. How is starting out with two to five times the JS that should even be part of a normal site's template (not counting social plugins), to then write two to five times the JavaScript needed to actually do any REAL task "easier"?

I don't think I'll ever understand the framework mentality, it has too much in common with "faith" on the use of propaganda techniques and outright lies to dupe the ignorant into believing bullshit. jQuery, bootcrap, vue, react -- endless pointless code bloat that encourage NOTHING but bad practices and result in nightmare shit-shows that are near impossible to maintain.

As I've said from pretty much the day I first encountered jQuery over a decade and a half ago, everything I've seen done with it falls into one of three categories:

1) Things that would have been less code without it, NOT counting the size of jQuery itself.

2) Things that are HTML or CSS' job. This has only become more true with CSS3.

3) Things that have ZERO DAMNED BUSINESS on a website in the first huffing place!

But sure, if you want to say screw SEO, screw accessibility, and screw actual users because I want "gee ain't it neat" whizbang BS that only impresses five year olds and bullshit peddling marketing executives, frameworks are your go-to.

All the claims about jQuery are card-stacked nonsense, they cherry pick situations -- often ones that shouldn't exist in the first place -- to try and make it look good, and beginners yum it up out of ignorance. Then after a few years it instills that wonderful cognitive dissonance through confirmation bias, until those who are basically mentally addicted to the BS cannot conceive of any other way.

Front end frameworks are a blight upon the Internet, and I can only assume that either ignorance or ineptitude are the root cause of why anyone would use ANY of them by choice.

MAYBE if people stopped wasting 100k of markup to do 16k's job, 500k of CSS to do 32k (or less') job, and megabytes of scripttardery on websites that don't even warrant the presence of JavaScript, they wouldn't be so easily suckered into thinking this framework bull is worth a damn.

The very methods by which it works are flawed. Take the ENDLESS POINTLESS IDIOTIC DIPSHIT "let's get things via querySelectorAll style methodology EVERY time we want to access it" that is $(selector). The various getElement/getElements/querySelector/querySelectorAll methods are memory and time consuming in the first place, but you go full Gungan with jQuery invariably you end up calling them non-stop endlessly. Store it as a variable or object property and re-use it.

Don't even get me started about how often people go even more half-witted using innerHTML style methodology via $().html(''), opening up security holes, increasing cpu/battery use, possibly triggering unwanted side-effects since it forces a full page reparse ... and all because "wah wah, I don't want to type appendChild and createElement!" -- cry me a huffing river.

WORSE is how people keep talking about jQuery as some sort of DOM helper, and then write codebases without ONCE doing a damned thing that ACTUALLY involves using the DOM. Joe forbid anyone actually bother learning how the DOM is structured and how to walk it. In Soviet Russia, the DOM walks you...

I maintain that those who defend the use of jQuery and use it by choice, either don't know enough about HTML/CSS or JavaScript to offer a valid opinion on the topic, or are nothing more than morons who will never truly be qualified to write a website properly.

It it wasn't for the mind-numbing reek of stupidity that is bootcrap, jQuery would be the #1 biggest monument to the stupidity of web developers.

NOTE, that's the watered down version. Care to hear what I REALLY think?

The ONLY thing jQuery is worth is a bullet to the brainstem. Actually, no, a shot to the head involves less brain damage.

 

Whoa! Are you really saying that the entire industry is misguided!? That's a pretty bold claim. I *am* curious to hear what you REALLY think, though.

So, you don't see any merit of jQuery making it more accessible and more comfortable for people to utilize JavaScript in any way imaginable? I'm learning to code, so I am just asking. So far, I found that most tutorials out there tell me it is important for me to learn how to use jQuery especially for low-budget projects in which I supposedly can't afford to spend all my time writing everything from scratch. Kind of make sense, but maybe there is another side of it?

 

That is REALLY what @deathshadow and many others here think that have thousands of posts on DP. Most people with few posts do NOT have DECADES of experience and therefore LACK the experience to make sound judgments about issues like these.

If you REALLY want to know what @deathshadow thinks, click the links at the bottom of his posts.

jQueery, Bootcrap, Turdpress, and all of the other bloated piles of manure are burying the entire web in pages using TEN times or more code than needed. Further, that code is FULL of security holes that no one is plugging making the entire web a dangerous place to visit. Worst of all, it is impossible to fix those problems, because when you fix one issue, you create one or more issues with your fix. In the end, using that crap gives you a LIFETIME job of either working for FREE to fix the fixes of the fixes ad infinitum OR hiring someone to spend HIS life fixing the fixes of the fixes, etc.

 

Whoa whoa WHOA!! Hold on a sec; now, you are adding Bootstrap and WordPress to the list of "turdware." These are all widely used industry-standard software. Are you implying that over 30% of the people building their websites with WordPress are dead wrong?? Wouldn't be so tedious to set up a custom blog site if I can't use WordPress?? I've seen literally dozens after dozens of Bootstrap tutorials some well-known developers teach. Are you implying that they are all WRONG??

What's wrong with ease of use and ease of development? Don't you think it's good that people have an easy and friendly way to set up a website that they can update easily? And how do you build a website with interactive elements without jQuery? I've done a few jQuery tutorials, so I know a little bit of how to do stuff with jQuery. It's easy, and a lot of third-party plugins and templates seem to require it anyway. I can only imagine how hard and time-consuming it might be to do the same thing without jQuery.

And, speaking of these things, what's with the whole command line obsession? I don't know, maybe I just don't know all the ins and outs of this stuff, but as another user, it seems kind of like a throw-back to 1980's when I see all these lines of code with dark background in many tech tutorial sites. Why haven't developers moved onto more visual tools for HTML/CSS? I can't help thinking we could do better in 2019.

 

Only have time for one point here.

The single biggest issue I have with jQueery is that, even when minimized, webpages are loading 384K of code for pages that often either don't use jQueery at all or only call it ONCE when the same exact thing can be done in 1K of javascript or LESS, often less than 100 bytes. And with CSS3, even a lot of that javascript code can be trashed.

How can you or anyone else justify loading 384K of code (stealing bandwidth from the user) when WHOLE pages deliver LESS than 10K of content?

Further, since jQueery is bloated javascript, how can one say it is easier to learn and faster to use?

 

Not sure... I just downloaded the jQuery 3.0 core, slim and minified, and it was only around 70K, not 384K. Why is 70K a big deal especially now that even phones in the countries with the slowest mobile download speed still reach 3~6Mbps?

 

Just because something is popular doesn't make it good. Or quality... or even right. See the current "fashionably bigoted" nature of American society. I liken it to the tone-deaf masses who yum up untalented auto-tuned Bimbo's like Beyonce because they've never heard an actually talented vocalist like Amy Lee or Floor Jansen... or try to put the artificial manufactured "beauty" of the person and the slick packaged marketing spiel ahead of actual skill.

The majority of claims about jQuery are exactly that, the marketing blurb unsupported by facts. At best it is disinformation, at worst it's a blatant bald-faced LIE. Same for every other front-end "framework" and the levels of incompetence that go with them.

Basically, any idiot can call themselves a professional; doesn't mean they actually do professional grade work. The general lack of regulation in this industry may allow for unbefore seen levels of innovation, but it brings with it a free-for-all of dirtbag scam artists who over the past decade and a half now dominate the industry. They've used confirmation bias and cognitive dissonance mated to the seven classic propaganda techniques to control the narrative... to the point I've been wondering if the people making systems like bootcrap and turdpress have been getting their inspiration from religion and politics.

How is teaching people to write more code than they need, to do things that might not even be JavaScript's job, whilst adding a second entire spec on top of JavaScript only to replicate EXISTING FUNCTIONALITY "more accessible and comfortable"? That's what I mean by the bullshit marketing blurb unsupported by facts.

If you are just learning, wouldn't it be easier to have to learn less stuff? Wouldn't it be easier to write less code? Wouldn't it be easier to not just blindly slap complex JavaScript into places where you don't even need it?

It's a house of cards build on a foundation of lies.

... and again the use of the glittering generality. How is more code requiring more knowledge requiring more time for things that probably aren't JavaScript's job or possibly don't even belong on a website if you care about usability, accessibility, and sustainability better for your budget? At best it's the "Credit mentality" of spending more later for something you can't afford now, one of the fastest roads to failure there is. At worst they're either parroting what they heard out of ignorance and apathy, or flat out lying to your face.

Not all mobile devices will actually support gzipped content, particularly if the battery is running low. Some will even switch between them since it takes less power to send/receive than it does to decode LZH on the CPU.

... and it's not JUST about bandwidth. That code UNPACKED has to actually be RUN, and running 384k of Code that replicates itself into new objects each and every damned time you call $() sucks on memory like candy. People bitch about how much memory chrome tabs suck down, but that's their attempts to make shit code like jQuery run efficiently by adding results cache to things like querySelectorAll or the various getElement(s)ByXXX methods and building lookup tables as indexes for selector groupings rather than walking the DOM every blasted time. Though if people would just use the DOM properly and leveraged semantics instead of throwing endless pointless redundant tags and classes in there, it would be faster to just walk the DOM even with the "risky" method of recursion!

More crap you have to run, the longer the page is going to take to render, and the more CPU/battery it's going to chew. REGARDLESS of bandwidth use and actual file load times. It's a bit like how total file counts is often more important than file sizes thanks to "handshaking". The more separate files you have on a page, the slower it will load regardless of your rated connection speed. Raw bandwidth is NOT the only concern. Ping times, execution times (server and client-side), caching models, they all play a role.

ABSO-FRAGGING-LUTELY! And I can prove it.

Taken right from one of bootcrap's tutorials:

  <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>

Code (markup):

The PINNACLE of developer ignorance, ineptitude, and incompetence. Proof positive that not just the people using bootcrap -- but those who created it --
are unqualified to write a single damned line of HTML.

You can't start with an H5 as the first content-bearing tag without a H4 for it to mark the start of a subsection of. Right there it just told users with accessibility needs and search engines to f*** off. Having the H1 so far down the page and not even being the site title is equal measure of gibberish. NAV does not replace the semanitc meaning of lists, and anchors are semantically neutral so dumping them into a NAV tag is equally mentally enfeebled trash. The endless pointless classes for nothing, presentationa use of classes, lack of logical document structure, and all the other failings are why this is utter and complete incompetent trash.

Any competent developer would write the same thing as:

<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><a href="#" class="signup">Sign up</a></li>
		</ul>
		
	<!-- #top --></div>
	
	<div id="content">
		
		<div class="leadIn">
			<h2>Pricing</h2>
			<p>
				Quickly build an effective pricing table for your potential customers without the bootcrap. You can build anything you want with complete customization in a fraction the effort without some dipshit framework!
			</p>
		<!-- .leadIn --></div>

Code (markup):

Using the DIV as styling hooks without saying what that style IS, not throwing multiple classes at everything for no good reason, and using the proper semantics so that non-visual user's and search engines aren't stuck there trying to make sense out of the gibberish structure. Using 2/3rds the code as well. Completed customized bootcrap designs more often than not end up using two to five times the HTML needed, and it's not like bootcrap writes that HTML for you -- but sure, tell me again how much "easier" it makes doing things.

If you care about usability, accessibility, long term costs of hosting and maintenance, security, profitability, or any other meaningful metric? They are so wrong they may never be right again.

Sleazy shortcuts based in lies are popular all the time. Wizards first rule: People are dumb. They will believe a lie because they want it to be true, or worse are afraid it might be true.

To which I would add that once they accept that lie, they will do ANYTHING to cling to it rather than be proven wrong. Even get themselves fired when someone like me is hired to come in and clean up their mess. I've seen that first hand. There's a reason half my job as a freelance accessibility consultant involves also being a hatchetman... and why now that I'm financially secure to the grave I'm getting out of the business entirely. I'm sick of it.

That's my huffing question!!! Given the endless nightmares, headaches, and EXTRA WORK these "frameworks" cause for people creating the back-ends that the end-user will be stuck with, HOW DOES ANY OF THIS ease use or development?!?

Yes, end users won't be dicking around with HTML, CSS, or JavaScript. That is NO excuse for people making CMS, templates, and the rest in HTML, CSS, and JavaScript to go full pakled handing those end users utter and total bloated, slow, incompetent, hard to maintain crap that took two to three times longer to customize for that user!

"Interactive elements" falls into mutliple definitions:

1) Stuff HTML/CSS can do without JavaScript.

2) Stuff that should be written to work without any JavaScript FIRST for accessibility reasons.

3) Stuff that would be simpler and easier to code without jQuery, possibly combining the power of JS with the heavy lifting skills of CSS3.

4) Artsy fartsy "gee ain't it neat" BULLSHIT that has ZERO DAMNED BUSINESS on websites if you actually care about users doing what it is they came to the site to do. ACCESS THE CONTENT!

Look, I got it done in a week!
<gunny>But you left half your god-damned user-base behind! CONTENT goddamnit,CONTENT!!!</gunny>

Which is why most of the time you hear "interactive" being used as an excuse? RUN.

I've done a few jQuery tutorials, so I know a little bit of how to do stuff with jQuery. It's easy, and a lot of third-party plugins and templates seem to require it anyway. I can only imagine how hard and time-consuming it might be to do the same thing without jQuery.

Depends on the task. Command line often gives you more control. Command line you can do remotely via SSH to the server. Command line doesn't suck down resources that might be better reserved for the things that require such like photo, video editing, and having 20 tabs open in each of the four major browser engines simultaneously.

Though there are things -- especially dealing with *nix and *nix-likes -- that "having' to use the command line pisses me off. Certain editors are really bad this way (vi, emacs) leaving me screaming at the screen "For f*** sake, just let me type the damned text in. If I wanted this level of needlessly cryptic commands I'd drag out my Trash-80 model 12 and boot up Xenix!"

But in a lot of cases, the command line lets you type in a dozen characters to get done in under a second what would take five minutes of clicking through window after window of BS.

Because it was tried, REPEATEDLY, and it's been a train wreck disaster EVERY BLASTED TIME. WYSIWYG's aren't some new grand idea. Frontpage and Netscape Composer are the bleeding edge of late 1990's web development mentality, and universally the pages that resulted were broken, bloated, traiin wreck laundry lists of how NOT to build websites that were broken between different browsers, inaccessible to non-screen media users, and wasted bandwidth at a time when there was no bandwidth to waste.

The facelift that was Dreamweaver did NOTHING to improve that situation. The various "wizards' to auto-generate code vomiting up some of the worst practices we've seen in web development. Practices people blindly use or copy to this day that result in fat, bloated websites all because "wah wah, eye dunz wanna learn". Fine and dandy for some crappy little personal site, but a complete DISASTER for business.

WYSIWYG's don't bring the idea of semantic markup to a page. As such they flip the bird at usability and accessibility. They inherently build things based on appearance, when websites are about MORE than just one magical screen media appearance. In the process they vomit up many times more code than needed, make doing even the simplest of changes HARDER, make it harder to add things the WYSIWYG wasn't designed for, and often break their own markup because the process is too complex for any automated tool to handle properly!

It's not an improvement, we ARE doing better in 2019, by kicking all that crap to the curb and going back to basics and the entire reason HTML was even created in the first bloody place!

Frameworks bring the same level of derpitude to the manual coding side of the equation. Blindly including code you don't even understand, to do things you probably shouldn't even be doing, in a way that takes MORE effort than if you had just bothered learning to use the underlying language properly in the first place. It's why those who sing the praises of all these bloated off the shelf answers are doing nothing more than screwing themselves, their clients, and their profits in the long term. Again as I mentioned on another reply to you, the credit mentality, pay more later for something you can't afford now.

Which is why those out there who claim to be "experts" but don't know what's wrong with code like

class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow"

Code (markup):

...need to back the F*** away from the keyboard and go take up something a bit less detail oriented like macramé!

Using such "frameworks" or "WYSIWYG editors" -- at least for business -- is for all intents and purposes going full Gungan.

 

@deathshadow

Is SCSS in the same category as jQuery in terms of its redundant nature? I wonder about whether having duplicate declarations have a noticeable performance impact on web page rendering.

For example, SCSS seems to boast about its ability to use variables like "$body-color: #000;". But, doesn't it go against not repeating codes? I learned to to this:

.selector 1,
.selector 2,
.selector 3,
.selector 4 {
  color: #000;
}

Code (CSS):

Which is worse: multiple selectors, or multiple declarations?

 

SCSS / LESS / SASS are their own separate ball of earwax.

As you correctly noted the alternative to variables AND "mixins", you've already found the implementation flaw, but it runs deeper than that. The big issues I have with all this CSS pre-processor nonsense are:

1) It's something else to learn on TOP of CSS. It's big enough as it is.

2) It's another step in your build/deployment process. Because of course having more steps is "easier".

3) The code that is deployed (actual CSS) bears little resemblance to what you write with it. This can really be a pain in the ass when working with others or if you come back a year or two later and you try to use the document inspector to figure out what rules are applied. The browser NEVER sees the actual SCSS code and only receives the 'compiled' CSS. As such working your way in reverse from what is rendered to what is coded is far, FAR harder to do.

4) If you're writing enough CSS to "need' any of the alleged "savings" in effort SCSS and its ilk provide, you've got too damned much CSS!

Again, for the nimrods and know-nothings who vomit up 500k of CSS spread out over a dozen separate files, where they have two to ten times the HTML they should by throwing classes at everything, I could see them being easily deluded into THINKING this level of derp is useful. For those of us who can do that exact same layout and functionality in 48k or less in a single CSS file with a fraction the markup they slop in there, not so much.

CSS isn't complicated enough to warrant anything that SCSS and its kine does. In my experience those who find it provides benefits -- again -- don't know enough HTML or CSS to even have a valid opinion on the topic. EVEN if they've been doing it for years... just means they've been doing it wrong for years.

Or worse, doing artsy pointless crap that has no business on a website anyways, or obsessing over everything appearing 100% the same in versions of IE we can stop giving a flying f*** about appearance in so long as the site is still usable.

Much akin to the derps who cried "but I want the rounded corners, shadows, and gradients to work in IE8/earlier" -- oh noes, you don't get rounded corners, shadows, and gradients in older browsers. That's SUCH a deal breaker they were throwing JavaScript and IE's proprietary VML at it...

Idiocy that continues today with HTML 5 stuff, and such halfwitted BS as "modernizr.js" and such.

 

Technologies such as AngularJS, React & VueJS came and JQuery looked outdated. People began to question the latter's significance. Since one is a library and the other are frameworks, their use cases never completely overlap. A library is good at what it is supposed to do and may not be good for what it is not supposed to do, and vice versa.

Jquery is still relevant but not as loved as it was before

 

I agree. Jquery, much like php courts bad press these days. However this is mostly from the younger 'geeks' that don't like to use tried and tested technology.

You have to say that recent workflows in web-development have been based on what, Google, Facebook, Twitter etc deploy. Of course we all work on those hugley complex heavy team-work projects, that ping our servers 1000's of times a minute, don't we? It stands to reason - why not lets introduce them into our 15 page garden landscapers website, just for the sheer hell of it. You know to workflow, let's use the terminal to download a 50 file scaffold build folder to produce a simple responsive structure that can be produced in 20 lines of code or less and while we are at it let's create a few files and folders via the terminal, deploy git at the same time, sass and pug.........hummm be sensible is my suggestion.

I wouldn't advocate using a heavy library just to deploy a simple pop up but if youre already using Bootcrap, a plethora of third party jQuery driven plugins etc I see no problem, other than maybe revise how you code in future - start slowly weaning yourself off of using bloated workflows. Having said that I do use Vue but not the CLI version, just the CDN. Does it do anything that vanilla javscript can do, no, its just currently trendy but I would not recommend bypassing learning some vanilla javascript before you progress to a framework because at some point you will need to deploy javascript alongside a framework.

 

Everyone will have their own opinion on how to develop or design. Everything that has been said here has some truth and merit however it's greatly exaggerated. Libraries and frameworks like Angular, Vue, Jquery etc all serve a purpose. And anything created with those libraries can be created with plain javascript. At the end of the day it's all plain javascript. There is an advantage on using a library if it reduces the code you write and make it easier to solve certain problems by simplifying the code written or by doing things in the back end that you don't have to worry about. However, it comes with a price and that price is often "bloat". I've said this before and I'll say it again... a lot of times this excessive bloat that comes with a cost is a minimal cost. More than likely the majority of web sites you frequently visit will use some sort of bloated library and you won't tell the difference as a consumer. Most of the time your computer and phone is powerful enough not to blink an eye at a coding library. Most of the time your high speed or even 4g connection is fine to load cache-able libraries and you won't notice a loading difference.

With that said... use what you want if you think it will make your more productive. One thing I will point out that sometimes using a library can limit you. The time spent learning how to use the library and working through it's kinks and limitations probably could have been spent learning how to write the code more efficiently. Then there are times that the library really isn't saving you time or coding. The majority of developers out there will use libraries with the intention to write less to do more. They are working smarter than the guy or girl who feels they need to write everything from scratch and reinvent the wheel each time.

You will encounter a lot of STRONG personalities on here. They will attempt to force their opinion as fact. They will also lead you to believe they know whats best. Most of the time they are wrong. Most of the time they are dated on their knowledge of technology and coding. Then there are people who really do know whats best..... but what is best for them and their skill set that was built over decades of sitting in front of a computer learning. They have a wealth of knowledge but it may not be realistic for you to apply. You have to take everything you read here with a grain of salt. You can spend your entire life coding away to impress the nerds and geeks of the web but that won't put a dollar in your pocket. A lot of the geeks on here don't know how to adapt their coding knowledge in to real world scenarios and make a dollar. A lot of these guys can't apply tech logic to business logic. A lot of these guys are too smart to make a dollar. Which is funny to me.

 

What is terrible practice these days, in my opinion, is going straight into using frameworks/libraries/plugins without understanding the methodology behind them. Unfortunately that is as a result of pressure these days to turn around a project in the shortest possible time and make as much money for management, who probably don't code anything any longer and who quite possible have never coded anything in the past. There is a great movement to using frameworks, libraries, plugins, automated workflow these times. It might be a successful approach financially but on the whole the job of a web-developer has become ever more shallow, unskillful and unsatisfying, as a result. Once money becomes the main driving force to do anything and the passion is no longer, you become more akin to a robot, 'colouring by numbers', not a particularly skillful or satisfying thought for the next 25 years or so.

I suspect there are some that are stuck in the past but they also have wise heads on their shoulders, so to dismiss their opinions is rather short-sighted. Times are changing fast, its now so obviously a race to the bottom as a concequence of polarised opinions and too many possible workflows at ones disposal. Good luck to those just staring out, its a mine-field to pick your way through.

The newer breed of web-developer is hooking up something like css animate or animate.js, (I wont mention the default Bootstrap files) - big and bloated solutions, just to harness a very small part of what they contain to execute something which can be done in a few lines of vanilla coding. Hence these days it's not unusual to observer 20-30 linked css/javascript files, no wonder we needed http2 as a result of bad practices and eventually that won't be effect or efficient.

 

Any coder who writes everything from scratch is systemically incompetent. Any coder who uses a generic library without having removed the cruft is also systemically impaired. If you know enough to personalize a generic library, you probably won't bother. They are built to be all things to all people.

The key is to build your own well documented libraries from well documented snippets you've written, copied or stolen* and saved. No reinventing the wheel, no linking to a sh-tpot of multiple js files and no sh-tpot of code you don't grok in fullness.

* Picasso was quoted as saying, a good artist copies; the great artist steals.

 

I agree with that approach. No need to re-invent the wheel each and every time. A good coder, as you say, should build up a chest of code snippets that they for the most part understand. Sadly too many websites are built by too many 'developers' using the default libraries/frameworks simply because it's quick and dirty to do so, rather than just cherry picking the parts they really need.

 

Which is the part I really don't get... how is using more code that costs MORE money to host, that makes you write MORE code than you need, that takes MORE time to develop, that likely alienates potential users creating MORE bounce and MORE visitors to sites going somewhere else, that costs MORE to maintain, is HARDER to maintain due to its painfully cryptic nature... making it "about the money?"

These dumbass frameworks if money were the driving force is the equivalent of lighting your cigars with hundred dollar bills.

I do not get where hell anyone can find ANY of this idiocy to take less time, less effort, or to save you a damned thing. The ONLY reasonable explanation is 3i. Ignorance, incompetence, and ineptitude!

Again, Wizard's First Rule. People are dumb. They'll believe a lie because they want it to be true, or are afraid it might be true.

 

This is why you are broke and unemployable. You clearly don't understand. Using Frameworks save your team time because 1. The library provides a structure and organization to your code (ie. the next team member can easily take over or assist). 2) Libraries generally provide functionality that you do not have to spend time writing and 3) Libraries generally are well documented and the code can easily be learned. That is why using libraries are preferred when working with teams. The less time you spend on developing the less money a company is spending on development. Corporate and Commercial development is all about how fast you can go from production to deployment. No one gives a sh^t about hosting costs, server costs etc. We need a finished product NOW to start making money NOW. Get it? I bet you don't...

 

Which I'm not broke, I've got people trying to get me to do stuff even when I'm supposed to be retired on medcial. But most people I know are in dire financial hell -- do you not watch the news?

Difference is, I actually give a shit about other people. It's called empathy.

Good for a laugh though, hey look it's the "Real World" lame excuse for not being a web professional. Christmas on a cracker it's like you quote the bloody thing chapter and verse.

You use all the same lame excuses to try and cover up for 3i.

Correct, I don't understand these BALD FACE LIES about ALLEGED savings.

Aka what semantics, good practices, and understanding the POINT of HTML and CSS provide out of box. The only reason anyone thinks they don't is being suckered by scam artists like W3Schools or having their head wedged so far up 1997 style HTML 3.2 markup that we need to call an orthodontist to handle the extraction.

Because of course, ignoring the structural rules of HTML whilst pissing out two to ten times the markup makes it "easy" for the next poor shmuck to deal with. Sure it does.

Assuming it does what you want, and you don't end up struggling to get it to do things it was never meant to -- much less that unless you're doing dipshit blind cookie-cutter copypasta any nube could do in 30 minutes training these libraries/frameworks typically make you write MORE CODE than you'd have without them.

Or worse, implement functionality that already exists or is none of their business. See all the derpitude out there of using JavaScript to do CSS job, JavaScript to do HTML's job, and JavaScript to tell large swaths of users to go F*** themselves.

Whilst the underlying languages are not? I mean we have MDN FFS...

... and I don't see how their bloated and often cryptic code is somehow "easier to learn". It's the OPPOSITE of that!

Aka the credit mentality -- pay more later for something you can't even afford now. Basically what you are saying is "who gives a shit if it screws the client next month if we get paid today". That's sleazy, unethical, and involves liability. Short-changing yourself at the start is how you fail. Again, people wonder why 90%+ of internet startups fail in their first year, and how the web presence of most brick and mortars is treated as an advertising expense and not a possible revenue stream. Something REALLY stupid in the case of advertising income driven news outlets and their ilk.

But worse, that's assuming that somehow not using these dumbass frameworks is somehow magically going to be "harder" or "take longer" or any of these other unfounded claims that are -- as I've said many times -- either delusional, ignorant, or intentional bald faced LIES!

... and then you wonder why @Gary-SC is asking about the ethics of this. Again, if this were actual engineering that attitude would be considered criminal. It SHOULD be treated as criminal because all the developers who make these bullshit claims are FRAUDS!

But no, you'll keep claiming what I'm saying is the slower approach when it's the other way around... where these teams of framework dipshits will waste weeks on what should only be about 4 to 8 man-hours work from SCRATCH. Made worse by results that will cost many MANY times any price difference in labor outlays by the time maintenance is figured into the equation.

You have to spend money to make money, and sustenance costs are an essential part of that. The "now now now plow the future" mentality? That's about as stupid as you can get in business unless your ONLY intent is to rip people off.

Admittedly in this age of corporate "to hell with the future of the company and its employees, how can we destroy this business whilst raping ever last one of its assets today" mentality, it's hardly a shock to find people defending these garbage practices and methodologies that reek of the same "how can I make a buck by ruining other people's lives and livelihood?"

It's why the entire concept of an "investor" is a relic of the past, no... they've been replaced by "shareholders" -- leeches upon the teat of society.