1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Should I still use jQuery with HTML5 in 2019?

Discussion in 'HTML & Website Design' started by Gary-SC, May 31, 2019.

  1. #1
    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.
    SEMrush
    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?
     
    Gary-SC, May 31, 2019 IP
    SEMrush
  2. sarahk

    sarahk iTamer Staff

    Messages:
    24,964
    Likes Received:
    3,392
    Best Answers:
    99
    Trophy Points:
    615
    #2
    Always know how to do the vanilla version before you use the jQuery version - a bit like knowing how to do maths on paper before you use a calculator.

    jQuery speeds up development and you are crowdsourcing functionality - some of it might be crap code but most of it will be good. Add too much to your page and you'll definitely have "bloat" but in most cases, it's worth it.
     
    sarahk, May 31, 2019 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,801
    Likes Received:
    1,593
    Best Answers:
    229
    Trophy Points:
    515
    #3
    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.
     
    Last edited: Jun 1, 2019
    deathshadow, Jun 1, 2019 IP
  4. Gary-SC

    Gary-SC Greenhorn

    Messages:
    60
    Likes Received:
    13
    Best Answers:
    0
    Trophy Points:
    13
    #4
    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?
     
    Gary-SC, Jun 2, 2019 IP
  5. mmerlinn

    mmerlinn Notable Member

    Messages:
    2,148
    Likes Received:
    262
    Best Answers:
    6
    Trophy Points:
    260
    #5
    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.
     
    mmerlinn, Jun 2, 2019 IP
  6. Gary-SC

    Gary-SC Greenhorn

    Messages:
    60
    Likes Received:
    13
    Best Answers:
    0
    Trophy Points:
    13
    #6
    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.
     
    Gary-SC, Jun 3, 2019 IP
  7. mmerlinn

    mmerlinn Notable Member

    Messages:
    2,148
    Likes Received:
    262
    Best Answers:
    6
    Trophy Points:
    260
    #7
    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?
     
    mmerlinn, Jun 3, 2019 IP
  8. Gary-SC

    Gary-SC Greenhorn

    Messages:
    60
    Likes Received:
    13
    Best Answers:
    0
    Trophy Points:
    13
    #8
    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?
     
    Gary-SC, Jun 3, 2019 IP
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,801
    Likes Received:
    1,593
    Best Answers:
    229
    Trophy Points:
    515
    #9
    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.

    [​IMG]
     
    Last edited: Jun 3, 2019
    deathshadow, Jun 3, 2019 IP
    mmerlinn likes this.
  10. Gary-SC

    Gary-SC Greenhorn

    Messages:
    60
    Likes Received:
    13
    Best Answers:
    0
    Trophy Points:
    13
    #10
    @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?
     
    Gary-SC, Jun 15, 2019 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,801
    Likes Received:
    1,593
    Best Answers:
    229
    Trophy Points:
    515
    #11
    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.
     
    deathshadow, Jun 15, 2019 IP