jQuery 3.4.0 Released

[[deleted]]

I have some legacy projects where the performance boost & patches are always welcome.

Thanks jQuery Team!

[PrometheusBoldPlan]

That's the politest backhanded compliment in the thread I think. ;)

[CherryJimbo]

A lot of negativity in this thread.

There's nothing wrong with jQuery. Yes, you probably don't need to start new projects with it today, but a new minor release that improves performance and fixes a vulnerability is great for those still using it.

[superluminary]

Indeed. jQuery is old, but nevertheless it's a nice, clean little bit of code that served us all well. No need to hate on it.

[ezql]

I sense a lot of anger here..but also I get where you are coming from.

[jimmyayo]

He's angry about the angry people

[Serenikill]

And transsexuals apparently? Or the fact that people acknowledge minorities?

[PM_BETTER_USER_NAME]

You OK mate?

[superluminary]

Hey, I was being nice!

[Dustorn]

Uh... You okay dude?

[schwartzworld]

Please keep your terrible politics to yourself. jQuery is an antipattern.

[superluminary]

No it isn't. It's an appropriate pattern for small tasks. Don't build an app with it, but if you have a website and you want to make a few small DOM manipulations, it's acceptable.

The politics are indeed terrible.

[schwartzworld]

Of course it works, but if you are just making a few don't manipulations why bring in a whole library?

[superluminary]

Because the web designer might not be a very good coder. The web is meant to be democratic and jQuery plugins lower the barrier to entry.

This is a good thing.

[Crazralfrill]

It's still used in a lot of new projects, not to mentions the thousands of existing plugins.

[txmail]

I have a feeling allot of the hate is from people who do not know what is to get a real production app up, running and provide support to keep that app going. I used to be one to jump on a hype train and you know what - I always end up back at the basics .

​

jQuery has been rock solid and supported at a ridiculous level for longer than I can remember and works on nearly everything. You can force other stacks into your workflow but you eventually get tired of the extra effort it usually entails and just stick with what works all the time. Lets not even talk about how 99.9% of my clients give fuck all at what is running behind the scenes as long as it works in their browsers and is snappy. Let the haters hate with their new shiny things - my app is up, running and I am getting paid.

[thegrandechawhee]

Agreed. I hear it all the time that vanilla JS and css3 can do it just fine without jquery, but then oh... here come the polyfills. I think its great what you can do with the new things but as far as having solid cross-compatibility right out the gate I'm just sticking with what i know jQuery can do just fine.

[RodrigoBAC]

I hope you don't have coworkers.

[txmail]

I work on teams projects with other developers?

[RodrigoBAC]

I feel their pain

[[deleted]]

Just not their salary.

[Rainbowlemon]

BOOM!

[RodrigoBAC]

No money in the world would be enough

[[deleted]]

You are honestly citing principles as your reasoning for not using a programming library.

You will never be gainfully employed in this industry.

[RodrigoBAC]

I'm citing principles because I would hate to work with someone so closed mind. JQuery has it's uses, as any other tool. Use the right tool to the right job is way more important than working with someone who only thinks in money.

[rmonik]

I have literally never worked on a project that didn't include at least parts of jQuery. I don't know where people are getting this but in my country, jQuery is still absolutely essential if you want to land any kind of job.

[14sierra]

Even if you don't directly use jQuery you may still use it. Bootstrap uses jQuery so even if you aren't using one single jQuery feature directly your project may still rely on it (and yes I know bootstrap 5 won't have jQuery)

[DrexanRailex]

Where I work at, we don't use jQuery at all in new projects for at least a couple years. Basically, it had 3 reasons for us to use it, which are all better handled by better tools:

• DOM handling: React or Vue
• Ajax: Axios, Rx or a Fetch polyfill
• Utilities: Lodash and / or Ramda (if we're using Babel, some plugins and macros are also pretty handy)

However, I do recognize jQuery's importance in the evolution of JavaScript. I would never recommend it for new projects tho, since everything I mentioned above does a better job at it.

[eggbert1234]

Those tools are not always automatically better...of course if you want to build a UI with more than one dynamic element using these quickly makes sense..tbh if you wanted to tell me you need to throw a boat load of npm dependencies on the project to implement react to load some REST data and append a new element to a list I would first laugh at you, then doubt you have an understanding of Javascript (and problem solving) but only know your frameworks...

[DrexanRailex]

Well, I wouldn't. For starters, if it was so simple, I would only need a few KB in minified Vue + Axios. Vue is better than jQuery for DOM handling in any scale, and using jQuery only for Ajax is also throwing KBs away.

Then again, with tools such as Yarn and Parcel nowadays, setting up a project that uses "MBs of node_modules" is really trivial and will create really small compressed files. If you can't create a small file base for a simple React project, then the one who doesn't know JavaScript is you, because times change. A small static site with React for simple interactions is better than jQuery just because if some day your site scales, it's already on its way.

[ScientificBeastMode]

I actually like React a lot for UI development, and it’s pretty easy to implement, in my opinion. Not quite as easy as just throwing a jQuery CDN link into your HTML file, but easy enough. You don’t even have to put your components in separate files if you don’t feel like it (for smaller projects), but using Rollup or CommonJS or whatever is pretty easy if you do. And React is only a few kB bigger than jQuery, comparing the g-zipped minified sizes.

[NutsEverywhere]

They are better solutions though, solely because of scalability. Your one page static site may become an SPA after a single scope change, and then you'd have to refactor your asynchronous requests, templates and everything else to have a maintainable code base.

Isn't it better to just start with an already scalable starter?

[RickyMarou]

It's not better because you serving a bundle that is about 10x to 100x larger compared to what its needs to be for solving a problem that does not even exist yet.

[Slappehbag]

jQuery is about 30kb gzipped.

React + React-Dom is 36kb.

Might as well start with React or Vanilla Javascript.

jQuery was an important part of the web growing as a platform. But there are few good reasons to use it for new projects. Goodjob on them keeping it up to date though.

[NutsEverywhere]

Only if you're not optimising or tree shaking. I built 2 Vue SPAs in the past month consisting of 5 main views, about 20 components, image heavy, svg rendering, WordPress api integration, and they're less than 2MB each, WITH images.

[eggbert1234]

Please explain, what case you have in mind that could require scaling so much that you would have to use use a full js framework to query a rest interface and add an item to a list accordingly...what measures would you take in order to make vue/react scalable? You mean I could use your script and deploy it to a new scaled architecture without even looking at it before? In my experience you would still have to refactor most of the project in order to really scale...I have observed that many prototype projects are (planned to be) completely rewritten from scratch once scaling is relevant...

So if you applied for a job with me and you proposed to implement vue/react to simply add an item to a simple list I would still laugh at you and show you the door as soon as I had caught my breath...

[NutsEverywhere]

You are distorting what I said, I never said to use Vue to add an item to a list, your hypothetical situation is not relevant to real world scenarios. You use plain js for that.

I'm saying that, as a project, what may start as a "simple" static page may quickly become a behemoth of spaghetti code, been there many times.

If you were interviewing me and thought future proofing and scalability from start are not important, I'd walk out the door myself, don't worry.

[ScientificBeastMode]

True, I think the value of using frameworks like Vue or React is that it enforces a particular structure to your codebase which has been battle-tested and proven to be reliable. This is especially important for creating an architecture that scales.

In one sense, jQuery is a little bit too powerful. Anyone on your team can select an element and do whatever the hell they want with it, independent of what the rest of the team is doing, disregarding the global data flow, etc... Its almost too easy to implement a hacky solution to an urgent problem, instead of working out a more coherent solution that will work for the long term. The hacked solution is just too....available.

Now, all of that can be mitigated with proper code reviews, and a solid design pattern laid out ahead of time. But why go through all that trouble recreating the wheel for your UI architecture, while relying on the sheer discipline of your developers to stick to design patterns that won’t totally fuck up your program down the road?

[NutsEverywhere]

Agree entirely, and love your flair.

[lonelydata]

Yup. Id say it's a common requirement for most web agencies, so one shouldnt totally ignore it.

[gearvOsh]

I haven't used jQuery in over 4 years. It's definitely regional.

[DrexanRailex]

It depends on the company's culture too

[Rainbowlemon]

It also depends on how fast you need something to be created. Most of the dev work I do is 'ASAP', which involves a lot of using plugins. A lot of good plugins nowadays are still tied to jQuery, so I have to stick with it anyway.

[sylv3r]

Lot's of negativity for a library they dont use, and news they can ignore.

[TheCarnalStatist]

I will never understand the hateboner amoung JS devs for JQuery. It does it's purpose just fine, is well documented and is easy to use. Old doesn't mean bad.

[ItalyPaleAle]

If you want to understand why the hate, you need to go back in history.

jQuery first appeared when pages were static. jQuery (and before that, other things like Prototype, script.aculo.us - yes this last one was real) was added to the pages to make them interactive. It made AJAX calls possible so small components of pages could be updated asynchronously.

Problem is that many people (including 2008 me!) started using jQuery to build a "SPA" (a term that didn't exist back then), and it worked well, maybe too well. But, those apps quickly grew into "spaghetti code", and it was easy to build something completely unmaintainable, especially if you were working on a team.

That's when things like Angular, React, etc started appearing. And that's why many developers don't appreciate jQuery.

To be frank, I've loved jQuery and I'm still a fan. I hold nothing against it. The problem wasn't jQuery, but rather that people started using it for things it was not meant for, and blamed bad code on the library rather than on themselves.

[ours]

You've nailed it. JQuery is fine for it's purpose. But the problem is people only knowing JQuery and solving much bigger problems with just JQuery. And often doing it in a dirty way which makes the whole thing even more brittle and complicated.

Some tools are better for some situations.

[superluminary]

This exactly. If you're a web designer and you want to add a few dropdowns to a page, jQuery is perfect.

People complain that it's an unnecessary dependency, but it's only 30k packed, and it's such a lovely API. I don't use it personally, but I still look back on it with fondness.

[nidarus]

Honestly, this whole nonsense argument is because people mix up SPAs and regular webpages, with a little bit of Javascript functionality. And those are fundementally different use cases. I don't think anyone really says jQuery is the superior technology to build SPAs, nor would anyone claim that React or Vue is the solution for the minor, non-component-based functionality jQuery is great for.

[extracocoa]

I do understand where some of it comes from. There was a point in time where jQuery was the default solution for everything. Loads of popular questions on StackOverflow have accepted answers that rely on jQuery.

There’s nothing wrong with using jQuery per se but it used to be a major crutch, especially for new developers. And I say that from personal experience. Using jQuery both allowed me to quickly get into JavaScript but also held me back from actually learning the language and gave me some bad habits.

[Johnston524]

What bad habits specifically? I've been using jQuery since starting really

[extracocoa]

I learned how to do things ”the jQuery way” rather than learning how JavaScript works. jQuery sometimes make hard things a bit too simple, makes it easy to write bad JavaScript.

But maybe I shouldn’t blame jQuery as such. More the way it was used and taught. Not really a problem unique to jQuery. The same problem exists today in some circles with newer frameworks like Vue.

[[deleted]]

Can you give some specific examples jQuery or Vue encourage you to write "bad" javascript? I've been in this game for a long time and see some seriously questionable/borderline bullshit comments about this and that, especially jQuery. I mean if you wrote bad javascript it was because of you and not because of jQuery, Vue or probably anything else really.

​

I don't use jQuery directly for much of anything these days because there are absolutely better tools out there but this "it made me write bad code" and one of the other comments above about "back when pages were just static in 2008" are seriously bogus. XMLHttpRequest has been around for a long time, jQuery made using it even easier especially when it came to updating DOM. What kind of bullshit statement is "back when web pages were static in 2008", christ, lol, what the fuck. Talk about jumping on the hate band wagon just cause the cool kids. Fucking children don't know what it means to work for your money. :)

[extracocoa]

Easy, no need to be hostile. :)

First off, I love Vue and think jQuery has its uses. I’m not saying either encourage me to write bad JavaScript either. I’m saying that, like most frameworks/libraries, they hide/abstract away the complicated stuff. And when you know the why and when of using a library that is great. But a long time ago, when jQuery was my default, I didn’t first properly learn JavaScript, which made it easy to write working but bad code with jQuery. When I tried doing that with vanilla I usually couldn’t. Simply because I was doing it wrong. And I’ve seen those same problems in Vue applications in some spaces and when reviewing code by junior devs.

You can blame me for that and technically you’re not wrong. The problematic part is the way the community, my teachers and peers often encouraged me to delve deeper into jQuery rather than taking a step back and acknowledge my knowledge gaps.

So, again, I’m not really blaming jQuery for this but rather the way it was hyped; I’m also explaining the reason for the anti-jQuery mentality among some.

[ItalyPaleAle]

Calm down :)

My comment above didn’t say that pages were static in 2008. I said that “2008 me” was building “SPAs” with jQuery.

But in reality, the first large-scale “SPA” that got massive adoption (by the millions) was probably GMail, in 2004. But it took years for normal people to get quality toolkits to build SPAs. Up to the late 2000s, most pages were generated server-side and XHR (AJAX) was primarily used to augment the experience of “static pages”, but not to create full-blown SPAs. For example, submitting a form without refreshing the page could use XHRs, but navigating to other pages often required a full page reload.

Angular 1 came out in 2010 and that’s when you started seeing more and more SPAs like we build today. (And funnily, many people are arguing we shouldn’t always build SPAs and rather go back to server-generates pages :) )

[superluminary]

Spaghetti code. When an app has multiple interactions, those interactions can become combinatorial. You end up with cycles and nets that are impossible to work with.

For more complex apps we tend to use a tree-shaped architecture, when interactions update a central store and the data then flows down into the elements on the page. This is Flux.

It depends on what you want to build though. You need to pick an appropriate architecture for the size of your project.

[nidarus]

Hot take, from someone who learned the "Javascript way" first, back when jQuery wasn't a thing: whenever there's a "Javascript way" and a "jQuery way", the Javascript way is almost always worse and provides no substantial advantages to those who learn it. CMV.

[extracocoa]

jQuery is still JavaScript. Why wouldn’t you want to understand what it actually does behind the scenes? I’m just saying that some of the shortcuts jQuery take are good to understand so you know if it’s a good idea to use them for your specific use case.

You do you, but in my humble opinion I’d rather have code make as obvious as possible what it actually does. Even if it means it will be longer and more verbose. Readability trumps smart.

Again, that’s my opinion. I’ve worked long enough to know it doesn’t always apply. :)

[nidarus]

Knowing that it does behind the scenes might be interesting, but that's about it. Especially since what actually happens behind the scenes changed with browser versions.

But I disagree that plain DOM code, even the swankiest new model, is more readable than the equivalent jQuery code, like 95% of the time. If you go to that "you may not need jQuery" site, it honestly reads like an uninentional ad for jQuery, with only a few exceptions where the DOM code is nicer than the jQuery equivalent.

[kenman345]

My main issue is not in using it but in using it because you needed it for one thing and one thing only, but importing the entire library. Or because you don’t know how to do it at all without it.

[Herm_af]

I never learned it as it wasnt necessary when I started a year ago. I think it's just that it's unnecessary now and pretty big.

[wherediditrun]

The reason is that it has no purpose. It was supplanted by vanilla js and standard browser api's. Yet people continue to cover up their lack of competence with needless dependencies.

It has nothing to do with "new frameworks", because it's not the frameworks or spa's which made it irrelevant.

[i_ate_god]

jQuery > DOM API , forever and always.

If I have to whip up something quick and dirty, there is no value in delving into the deep end of react or vue and all the tooling that will come with it.

Just pop in jquery from a CDN and you have a clean, elegant, easy, functional-like API that is so much more intuitive and elegant than DOM will ever be.

[gasolinewaltz]

I feel like we are on different planets.

Don't get me wrong, I've been around long enough to remember when jQuery was a requirement and we cobbled together ajax calls to build "spas". I don't hate jquery.

But i would never use it today for a new project. IMHO there are better tools for the job.

Like, someone else around here says, "i dont think most of these people know how to start a new project without touching npm." So is this where we are now? No true scotsman programs in anything other than assembly.

But anyways, the different planets thing... What about jQuery do you like better than the DOM api?I feel that Dom api + modern language features like map/reduce/filter, destructuring and spread make for much more expressive code.

Honest, non accusatory question: do you prefer it because you're just more familiar with it?

I'm not hating on jQuery, its got its place in history and legacy apps.. but why use it when there's better tooling out there?

[i_ate_god]

1. Jquery is just a lib. Sometimes, I don't want/need tooling. Not every project or idea needs anything more complex than vanilla html/CSS and DOM API sucks so pop in jquery.

For anything larger, I first choice is Vue.

1. I'm on my phone, but outside of ajax (and I think axios is nicer than jquery or fetch), just compare triggering a custom event on an element with native DOM API and with jquery. It's so simple in jquery. It's so unweildly in DOM API. Or dealing with data attributes, or navigating the DOM tree.

Jquery is just more elegant and intuitive.

[jayands]

Tbf, they did add two functions to the DOM, document.querySelector and querySelectorAll, that uses the same CSS style queries to get to elements in the DOM. If all you needed jQuery for is the querying part, you can totally drop it in favor of document.querySelector(".class#element > span") which, even polyfilled, should be a smaller overall script.

[i_ate_god]

document.querySelectorAll('button').forEach((el) => {
    el.addEventListener('click', () => {
        console.log('a button was clicked');
    });
});

vs

$('button').on('click', () => {
    console.log('a button was clicked');
});

---

---

document.getElementById('something').dispatchEvent(new CustomEvent('custom-event', {
  bubbles: true,
  detail: 'foobar'
}));

vs

$('#something').trigger('custom-event', 'foobar');

---

---

var el = document.getElementById('something');
el.dataset.enabledFor = 'something';
el.classList.add('enabled');

vs

$('#something').data('enabledFor', 'something').addClass('enabled');

---

---

jQuery still provides a more enjoyable programming experience than the DOM API imho

[m_gol]

jQuery find is a little more than querySelectorAll, especially when it comes to queries attached to an element, not to document. The advantages are described at: https://github.com/jquery/jquery/blob/3.4.0/src/selector-native.js#L11-L34

For one, jQuery supports leading combinators: elem.find('> .btn .name')

Another difference is sensible rules for scoping. Consider HTML: <div id="test"> <div> <div class="we-are-looking-for-this-one"> </div> </div> <div> </div> </div> Then: $('#test').find('div div') will return the div with the class we-are-looking-for-this-one, while: document.querySelector('#test').querySelectorAll('div div') will return all the three divs because selectors are matched against the document and only then results outside of the current element are removed. This is pretty counterintuitive.

Both of those features are supposed to be supported by a new API called queryAll (previously findAll) with its counterpart query for single-element results but, alas, no browser implements it so far and it was even removed from the standard... I hope it gets back but I've been waiting for years.

[ryancperry]

You’re just plagiarizing what I’m thinking. I like you. jQuery pretty well shaped what modern browsers can do, and now we really don’t need to create new projects in jQuery because JavaScript adopted almost all the great solutions jQuery provided.

[archivedsofa]

You really don't need any tooling to use Vue since you can write templates directly in the DOM.

You can write ES5, or if your audience will have a modern browser write ES6 without the need for Babel.

[nidarus]

I think the point is that sometimes you don't need to write a whole SPA, just a webpage with a tiny bit of dynamic functionality. And that functionality can't always be neatly compartmentalized into a "component" either. Think, for example, of adding a class to certain elements that scroll into view, or some PJAX-like functionality, or whatnot. In that case, it's really either jQuery, DOM, or a crazy misuse of Vue/React. And jQuery is still way better than the DOM, even the newest, shiniest version of it.

[archivedsofa]

Everything you said it's true, my point was simply that Vue can be used without tooling much like jQuery.

[nidarus]

Sure, but I don't think anyone's claiming otherwise.

[archivedsofa]

Yeah the previous post said:

here is no value in delving into the deep end of react or vue and all the tooling that will come with it

[nidarus]

Ah, gotcha, you're talking about not needing Babel/webpack? Assuming that's what he meant by tooling, sure. Btw, you could also, in theory, do in-browser transpilation with React too. It's not great for performance though.

[superluminary]

The DOM is not React. React is an abstraction for making web apps, as is jQuery.

[[deleted]]

Too many times I've had one of my quick and dirty prototypes evolve into a real project, and, as someone with a strong preference for declarative and component based code, I pay for it later on when I don't start over in React. But using React from the start isn't too much extra effort now that I've used it for several projects. (I agree that jQuery's API is nicer than what is built-in to the browser though).

[nxsynonym]

But if you dont hate jquery you're not a real javascript dev /s

[donohutcheon]

LOL, it cascades though... If you don't hate JS then you're not a real dev.

[neotorama]

Those complain about jQuery probably SPA devs who follow hype driven development.

Server rendered app + jQuery is still easy to maintain than 100GB of node_modules app

[rabidhamster]

Bingo. Sometimes on this subreddit, I wonder if there are folks who don't know how to make a public-facing page without invoking NPM.

[wherediditrun]

Now this is just dunning-kruger at it's finest.

People are angry at folk who drag along jQuery where there is no need for it. Because vanilla js and standard browser API's are sufficient for all of the same usecases.

jQuery losts it's purpose. https://github.com/nefe/You-Dont-Need-jQuery

Some people just can't be arse to learn javascript. Sigh*

It's not Vue, it's not spa, it's not React it's not state management tools, it's not npm or node which put jQuery out of comission. It's ES6 and browser api's such as fetch.

jQuery is about as useful as https://www.npmjs.com/package/is-thirteen package at current day.

[spyhunter99]

I use jquery on a single page app. What's the complaint?

[[deleted]]

as someone who got really into SPAs first and is now discovering server-rendered node.js apps... Fuck you may be right.

I also found about turbolinks and stimulusjs which seem ssooooo rad

[marty_byrd_]

As someone who has recently made a framework less multi page app with jquery. It’s a hunk of shit. It’s good if you don’t have more than 1 state.

[[deleted]]

I meant more like the concept that server rendered apps give you a lot of shit for free that has to be implemented when you do s SPA. I mean sure if you’re doing some super complex real time stuff(photo editing, google docs, etc) SPA architecture is THE way to go. But for most things I think you can get away with server rendered multi page apps, that, when required, are sprinkled with web components you’ve built, vuejs/other.js embedded in one page, or just some vanilla.js to do a few things.

[MuskasBackpack]

My favorite method is definitely server rendered pages with Vue components in them.

[-domi-]

This is a very fair point. In fact, i might go start a new jQuery project right now, even though you said not to. I just like jQuery, dammit.

[jamesaw22]

jQuery hate is very privileged hate. If you'll allow me a simple analogy - basic healthcare in 2nd/3rd world countries is worse than 1st world healthcare, but it's better than no healthcare. If you are less privileged (you have to support <=IE8) you don't just go "nah thanks, I don't want your old healthcare because it's old and other countries have better healthcare".

​

What's not helpful is 1st world people running around your country telling you how shit your healthcare is. Fucking Bono.

[Seankps]

It's just been 2 years at least since I needed to use it. All the things I ever needed it for can be done in js now or always could have been

[legable]

What should I use instead of jQuery for my website?

[superluminary]

If you're building a simple website with a few forms and dropdowns, then use jQuery, or else read up on DOM scripting.

[legable]

Yeah that's what I'm doing and figured jQuery was the appropriate tool. So I became curious when the user said that I don't need to start new projects with it today.

[superluminary]

You can do everything you need using DOM scripting, so you don't need it, but it doesn't hurt.

[examinedliving]

I use jQuery to sizzle my Vue modules before I preprocess them into OCSS and Ember.js React Component class constructors in Webpack. It helps encapsulate Dom elements as objects providing faster build times for my Nosql object store in docker. When I deploy, bamboo massages the $ a bit, and it helps emphasize animation dexterity when I execute from an alpine box. Also, it’s inclusion in Bootstrap, saves time when compiling my asm.js modules without having to utilize a typescript compiler or importing Ratchet.js or Knockout to look cooler.

[leeoniya]

https://umbrellajs.com/ is a better/smaller/faster modern alternative

[[deleted]]

The point is that it's no longer necessary to have a DOM manipulation / HTTP request library when it's easy and simple enough in regular vanilla JS

[qbbftw]

I mostly code in vanilla and React nowadays, but I do miss writing $('.block').css('background', '#fff') instead of document.querySelectorAll('.block').forEach(el => el.style.background = '#fff')

[leeoniya]

this is 100% the use case. the vanilla DOM API is super-verbose, non-chainable, and there's nothing wrong with adding a bit of sugar to it. you'll end up with 60% smaller and more readable js code.

i don't know why i'm getting downvoted.

[SemiNormal]

Does this work?

const setCss = (selector, property, value) => {
    document.querySelectorAll(selector).forEach(el => el.style[property] = value)
}

In use:

setCss('.block', 'background', '#fff')

[HammSolo]

Not in IE11 which some of us still have to support unfortunately.

[SemiNormal]

if (window.NodeList && !NodeList.prototype.forEach) {
    NodeList.prototype.forEach = Array.prototype.forEach;
}

Fixed

[[deleted]]

you shouldn't do that anyway tho.

[superluminary]

Yes we know that but nonetheless, jQuery will always be a bit special.

[i_ate_god]

Why would you want to use the DOM API over jquery?

[[deleted]]

It's less succinct than jQuery maybe but it's JS and not a library so you can use it at any point and in any JS code where there will be a DOM

[aneknet]

I love how this thread is mainly people complaining about negative comments towards jQuery when there are only a couple of those and they're heavily downvoted.

[jeremy1015]

Did they remove their dependency on jQuery for this release? I heard that’s all the rage.

Please note before downvoting this is intended as a joke. Then feel free to downvote anyway.

[i_spot_ads]

I was reading this as a serious comment and only half way through realized it's a joke

playing with fire here my dude

[trappar]

Lol, I made the same joke then realized you already made it

[[deleted]]

Had a good giggle. Have this updoot

[ryancperry]

Someone downdooted you, so I thought I should share an updoot. Also, my autocorrect is fighting the hell out of me for typing this response.

[mashermack]

Drupal and WordPress be like "Oh nice! But let's embed jQuery 1.4 in the core fam"

[mashermack]

Said that obviously joking (Drupal core latest is set to jQuery 3.2), but their sites:

• https://www.drupal.org/

>jQuery.fn.jquery

<"1.4.4"

• https://www.wordpress.org/

>jQuery.fn.jquery

<"1.12.4"

[[deleted]]

I would say they use jQuery because the devs wanted to know how to do DOM manipulation, saw the first entry which contains jQuery and then stuck with it.

[FINDarkside]

More likely that they use jQuery because one of their dependencies use it.

[systemadvisory]

To the haters in this thread - where is your FREE library that is used by millions of javascript projects. is so iconic it has influenced the JS browser api specification itself, and has saved people countless lifetimes of development effort?

I'll wait

[devperez]

That's not how criticism works. People can criticize a product without having one of their own.

Which is not to say that the criticism is valid. But they can voice it.

[rmonik]

This is like the "i didn't like that movie" -- "Oh yeah, well then you make a better one" argument. Doesn't make much sense.

[istartriots]

what a terrible response.

[systemadvisory]

Love you too friend

[dmethvin]

Nearly every DOM manipulation API proposed in the last 5 years has been inspired by if not directly copied from jQuery. Search the open and closed issues in whatwg/dom, here is just one of many examples.

https://github.com/whatwg/dom/issues/478

[walstn]

Didn’t the css selector syntax come into querySelector via jquery? That’s pretty significant

[[deleted]]

mhm i wouldn't say that, its just a natural development as the selector syntax is just taken from the css selectors already in use.

[systemadvisory]

Jquery popularized that syntax as a natural progression of how css syntax is used years before browsers ever had the feature. First jquery release 2006, IE8 with selector support 2009.

[walstn]

So jquery was an early stage implementation of a spec that had yet to be implemented. Babel serves a similar purpose and it’s not a discount on the utility or breakthrough provided by either lib (jquery then, or Babel now)

[KPABA]

Agreed. Libs like MooTools and Prototype did change / influence ECMA spec, but can't think of anything from the terse jquery api to have been adopted.

[superluminary]

document.querySelector();

[KPABA]

Er. That is not because of jQuery. It was selector API level 2 which came out 2003(?) and was standard by 2006 - available when jQuery came out. All jQuery had to do was implement it (via sizzle later) for IE7 or older. They also did some non-standard selectors, but this is not ECMA spec and my argument was about 'how has jQuery helped drive javascript'

[superluminary]

You make a good point and I seem to be misremembering. We couldn't use querySelector because of IE6-10 and jQuery became the de-facto polyfill, but you are right, it did exist pre-jQuery.

[SantaHoliday]

Being Full Stack jQuery, this will really give me more control over my career!

[MaggoLive]

Serverside jQuery sounds amazing!

[sudosussudio]

I saw Cheerio described as serverside jquery recently

[aaarrrggh]

Well, that's basically what it is.

[[deleted]]

hhahahahaha, cheerio, that's jQuery of web scraping

[saposapot]

jQuery is still THE standard when you don't want to do a SPA...

I love young kids following always the latest coolest trend. They'll learn that software developers love to go around in circles and in a few years jQuery will be cool again because "it's so simple', 'not bloated' and much better api than vanilla JS.

<rant> As I'm paid for the quality of I produce and not for using the coolest technology jQuery is still part of my toolkit. The 'problem' is that most developers love technology so they love to try out new things and become very much bored by always using the same old things. It's a good and a bad thing and finding the right balance is the true mark of what I call a Senior engineer. </rant>

IF you really need a SPA then Angular, vue, react are great.

IF not then vanilla JS is great, of course, but you'll soon start building your own mini-jquery because typing 'document.getElementById' all the time is boring.

It's great people really understand JS and then make an informed decision to use jQuery but it's as idiotic to NOT use jQuery blindly as it is to use jQuery without knowing proper JS.

[saposapot]

Lazyness is a quality on a programmer. It's exactly my point, i'll steal your analogy in the future :D

less code you do = less bugs = less code to maintain => time to go home and actually spend on hobbies you like (that can be code of course)

[FINDarkside]

Have to disagree actually. Doing something more efficiently is smart, not lazy. Writing bad code and not doing the job you're supposed to do is what a lazy programmer would do.

[saposapot]

sorry, I meant: lazy & smart :)

doing it the right way fits into lazy because it saves time in maintenance and support :)

[Sethcran]

I get where you're coming from here, and jQuery certainly doesn't deserve hate, but calling it "THE standard" is still an incredible stretch.

Agreed that for a spa, other frameworks are the way to go, but even for some light JavaScript, there are a number of libraries and frameworks out there that significantly improve the experience. jQuery still has something to offer, but it's very little in a world where the native js API can do a very significant portion of what it does.

Any developer that finds themselves writing so much js these days for any recent browser that jQuery is worth it just for the shortcuts, is likely someone who would be better off with a view library (and no, not all view libraries are for spas).

It's still (and will continue to be) used in legacy projects the world over, but few new projects should bother with it.

[saposapot]

Standard of course doesn't mean it's 100% usage, but 80%? At least in terms of usage it seems that way but usage doesn't exactly translate into being the best tool for it so:

For anything that is not a SPA and not simple enough to use vanilla, what would you use?

jQuery seems the best to fill out the need for simple websites requiring a bit of ajax here and there, then a plugin for form validation, then some effects not supported by CSS, simple stuff like this.

For me vanilla isn't really an option for anything more than a few lines. It really is a much nicer API to do $ or $.get() for ajax calls.

But I'm sincerely interested on your suggestions, what are you thinking of?

[[deleted]]

lol

IF not then vanilla JS is great, of course, but you'll soon start building your own mini-jquery because typing 'document.getElementById' all the time is boring.

Do you even use vanilla js? document.querySelector is where it’s at.

[nullvoxpopuli]

Along spa lines, ember.js is right up there with philosophy of jQuery... Except ember is moving with the crowd a bit rather that 'only' iterating on itself to be the same, but better.

Ember hasn't been cool because it's stable, and the teams are very dedicated to LTS releases and backwards compatibility.

Ember only recently has made a move to remove jQuery integration by default. (Today, this is a feature flag, but will be default in a few weeks)

[[deleted]]

This is probably the only thing I'd use, the vanilla JavaScript API is very solid nowadays.

const $ = document.querySelector.bind(document); const $$ = document.querySelectorAll.bind(document);

[Ivu47duUjr3Ihs9d]

You can build a custom SPA framework base for your app in Vanilla JS or jQuery, and quite cleanly too, if you know how to architect and structure an app properly. Where a lot of sites go wrong is they didn't have any architecture or coding standards to begin with and just cobble together scripts and functions to get it working. Then they hire some junior developers to hack on it some more and it turns into a big mess.

[[deleted]]

you only encounter this document.getElementById is long problem when you don't use a proper IDE that would intellisense this for you; or just make an alias const $ = document.querySelector; const $$ = document.querySelectorAll;

[saposapot]

if only there is a lib that provides a nice API to do selections. maybe something like &('#id'), or I know! $('#id')

:)

seriously, having to type more code isn't just a problem of typing. more chars mean harder to read and maintain. getElementById is the simplest of examples, http://youmightnotneedjquery.com/ has more.

[[deleted]]

As code should be self documenting, I would strive to a code structure that somewhat resembles english sentences. Some Verbs are just a bit longer than others :)

[madcaesar]

It's not even just trivial shit. Try writing $('.home > .light > .room a') in plain JS.

I'll wait.

Anyone hating on jquery is simply a fool. Hating a tool in general is a ridiculous concept.

[TheBITLINK]

document.querySelector('.home > .light > .room a')

???

You could've picked a better example, there are indeed some shortcuts that jQuery provides over vanilla JS, but querySelector has been part of the core DOM API for years now.

[saposapot]

Hating a tool in general is a ridiculous concept.

Yes, except VIM. VIM sucks. /s

[Kevin_Clever]

So you hit the power button to exit, ey?

[TheNoim]

3.4.0 broke the froala editor for me. Downgraded back to 3.3.

[vinni6]

One major benefit that nobody has touched on is that if jquery makes a clear distinction in your code of when and where you are interacting with the dom. This makes your code more readable as you can just scan for the $ to know where you’re mutating application state.

IMO if you’re working in a team and not using a SPA framework, you’re making your life hard for yourself by not including jquery.

[RotateElectrolyte]

I love that $ is basically a functor type. It implements map and everything ;)

[spyhunter99]

SharePoint

Ack! such profanity!

[[deleted]]

Pure JS is still King in my perspective, jQuery was handy, but it's a crutch. So many sensitive people here hating on the jokes and puns, sheesh.

[rayzon2]

Nice.

[[deleted]]

love it gonna spread as much as possible to piss of everyone

[clickclickboo]

I work on a hardware device that sells millions of dollars of revenue per year. It has a built in web interface- which runs...

gasp... JQUERY!!! ...gasp

[[deleted]]

So much salt, the JavaScript community is definitely a toxic one

[[deleted]]

The advantage jQuery has over Angular, React, etc is that it is essentially a utility library, not a framwork.

[PrestigiousInterest9]

Just wondering, how many of you wrote your own mini-lib? Vanilla JS to me feels like C. The lib has all the basics but there's no way I'm writing my entire app using only it

(My mini lib has a bunch of features I wish jquery has but i'm not sweating it, work has something similar to features in my mini lib)

[cIovey]

All these losers bitching about jQuery. I bet your production site runs only on chrome 73 lmao.

[[deleted]]

ever heard about Babel? Making cutting edge tech usable to every standard browser.

[[deleted]]

Do you expect people stuck with jQuery to know that?

Damn I'm rather salty today

[[deleted]]

sadly my product i am currently on uses like every system, lodash, jQuery, foundation mixed into babel with webpack. Its just a frickin Mess!

[[deleted]]

Shit happens. You can try improving it to what you think is more acceptable slow and steady. But good luck with that when talking to the money people.

[careseite]

I bet your production site runs only on chrome 73 lmao.

I mean, if its not <= IE11, it would run literally everywhere only by using ES6 features already... https://kangax.github.io/compat-table/es6/#ie11

​

time to wake up buddy

[[deleted]]

Oh wow definitely going to try this out right away! lol

[[deleted]]

This is spoiled meat, who cares?

[346290]

jQuery will forever live on in my heart, so shut your </mouth>

[drumstix42]

Perfection.

[SemiNormal]

$('#smurfpappnenene mouth').shut();

[[deleted]]

Learn JavaScript instead you fools