Removing jQuery is not always a good idea. The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ Look at how simple things are in the left column, and how much more code is needed in the right column.
jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected');
and you don't have to check for nulls after each selection.
Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge.
For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.
I was one of the developers who made http://youmightnotneedjquery.com. To be fair, we made it in... 2014? There is a lot you can do now which you couldn't do then, just with a browser. A lot of the challenging examples, like animation, you're better off doing with straight CSS.
Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage.
But in this case (as in many others), code is written just a couple of times per month, and executed millions of times per day in millions of computers all around the world.
Therefore this kind of "low level JavaScript"* optimizations will have a net benefit much, much bigger than the convenience of reading shorter code for a relatively small group of people.
Things have changed since then. For example, AJAX now is much simpler to use than it used to be.
async function printExampleCom() {
let response = await fetch("https://www.example.com/")
// NB: Response has other methods like json.
console.log(await response.text())
}
printExampleCom()
You need a polyfill for `Request` for Safari and Internet Explorer (but not Edge), but that's about it.
If you have even medium complexity you're better off using something like React with Babel or Typescript. Much more sane way of event handling than JQuery, and no mucking with HTML by hand.
I agree with JQuery for the most simple sites, but React+transpiler will give you much better compatibility
> Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge.
Many of these can be polyfilled, Going the polyfill route IMHO is a bit better. I use this now : https://polyfill.io .
Yeah, it doesn't serve the site well to include the animation and XHR stuff right at the top.
But if you had a small site that just needed to perform a few DOM manipulations, this would be highly relevant. If I just need to pop a div open and closed when a button is clicked, I sure won't bring in jquery just for that.
That's one paradigm that operates directly on the DOM, but, a lot of modern-day development tools (e.g. redux) don't work like that, and their programming model is a lot more straightforward than "remove the selected property from all siblings", instead just having a selected boolean expression for each element.
The performance question becomes a bit more tricky too then, because instead of comparing direct DOM manipulation you're comparing 'rendering' as a more abstract concept.
While we're on the topic of our favorite JS toolsets, I've been having a blast using just a ES6 transpiler and Greensock. No need for neither jQuery nor a giant SPA framework.
It isn't about writing code. As a developer writing code is your job. If writing a couple of extra lines of code makes you sad then perhaps this isn't your cup of tea.
For me it has always been about performance. jQuery is slow. Even way back in the day before JavaScript got fast you could access the DOM quickly if you knew what you were doing. Likewise DOM access could easily make your code 5 times slower if you didn't know what you were doing.
Since 2012 JavaScript has been fast in every major browser and querySelectors are a standard feature. Since about that time accessing the DOM has always been 10s-100s of times faster than using the standard querySelectors. In Firefox it is 10s of thousands of times faster. The standard querySelectors are faster than using modern jQuery.
To me this is the difference between a junior developer and a competent developer. Some people NEED the extra help. I understand that. If product quality and achieving a superior user experience are important though you will simply figure out a better way of writing code, especially since writing code is probably your job.
I'm impressed. I don't think the web would be where it is today without JQuery, and being able to completely pull it out is pretty awesome. Not because of JQ-hate, but web standards have improved that much.
I think it's a testament to jQuery's influence that, even though many of us don't use it today, we still often think in a jQuery way. The most useful common bits of jQuery's approach got baked into standards.
I think it's impressive that even when I'm not using jQuery (haven't in many years), I find myself writing code using features/capabilities where jQuery was an obvious inspiration.
jQuery was awesome, and needs to be entered into some kind of web-tech historical hall of fame. But it's time has come to be replaced.
I had used Prototype.js, and just a couple years ago finally gutted it from our code base. And shortly after started removing jQuery. It's a long slow process.
After starting with Vue.js, I completely understand why jQuery is no longer needed. Vanilla JS/CSS3 does 98% of what jQuery did for us, and our own micro-library fills in the blanks. And Vue is replacing all the jQuery scaffolded apps.
If it weren't for reactive interface libraries though, jQuery would still be a staple.
One example, I use a jQuery library for sorting tables. When I saw how sorting a table is so basically easy in Vue.js, that no plugins or 3rd party code needed, I saw the downfall of jQuery in general.
i offer wonder where the state of the web would be if John Resig never would have created jquery. i think everyone who is into web development today owes a thank you to him. jquery single-handedly made programming on the browser easier.
Around 8 years ago I was on a project where my boss told me the web app I'd be working on was really slow, and they needed me to help them speed it up. When I took a look at it, I discovered the app was using a multitude of libraries with overlapping functionality - jQuery, ExtJS, Mochikit, YUI, and I think a few others. Every previous developer had simply included their library of choice when working on the app, and it had made the app overly bloated (and complicated). Definitely a good sign that browser APIs and their polyfills have become good enough for standard web app development.
How much of the reaction to this is: "isn't it neat that web standards have advanced enough that we don't need jquery anymore," vs a pile on of: "jquery teh sucks cause it's old and stuff."
But native Javascript, as explained there, is more error-prone while jQuery (and Umbrella) are more permissive. Both have their pros and cons, but if you try to make native Javascript as permissive as jQuery you'll end up with a big mess. Unless you create some internal methods, which then you bundle, test, release, and... end up with another jQuery clone!
Just curious, does there exist a library that uses jquery syntax but with modern vanilla JS as the guts? i'm sure someone must have done this but i dont know about it. I'm interested to know if you could just replace the jquery cdn link for this and have your old jquery code still work?
Latest jQuery claims to support only recent browsers. I think it means that they are using relatively recent JS API without workaround or hacks if you're concerned about it.
Nothing but respect for jQuery. It has had such a wide range of influence on both javascript and the browser ecosystem. The good thing about a great tool is that when the problems it solves no longer exist and can be retired gracefully.
> What did we replace it with? No framework whatsoever
They bragged, about the single worst web UI I have to use on a daily basis. Github.com combines the worst elements of static and dynamic web-pages:
- If something gets updated on the backend, it will update on the frontend
- Except all the times it doesn't
- If you change something on the frontend, it will update on the page
- Unless you interact with the page in any way after that, like changing tabs???
What you end up with is a frontend that uses a lot of AJAX, but still requires constant hard refreshes to see accurate information. It's an absolute disaster.
I started my JavaScript career in 2011 with the two books "JavaScript - The Good Parts" by Crockford and "Professional JavaScript Techniques" by Resig.
Somehow all the time I'm doing JS, people were talking about how jQuery was "an old library" and "the old way to do things" even in 2011.
2 years ago I was on a JavaScript meetup and some guy, who did interfaces for stock trading, said: "We had to write our own framework, because jQuery just didn't cut it anymore!"
I just thought, no shit, it's 2016 and NOW you talk about replacing jQuery? Since its inception I used 4 different frameworks and even when I started in 2011 it was already "old news". Where have you been living if you had the impression there is only jQuery and "your own framework"
IMO, jQuery is still very usable for all the "almost static" web sites out there. Sure there are smaller and arguably better options out there, but there's no harm in using it if you're used to it.
I don't see why it being old is an inherent problem.
As noted by others, jQuery was essential in carving a path between the past of browser incompatibilities and the modern form of mostly reliable and evolving standards. It was hardly alone - other libraries did their part, evergreen browsers are essential, and the list of people doing a lot of thankless work is long and unassembled - but it was nonetheless an essential piece.
I want to clarify a bit about "JA Hate" though: Most of it stemmed not from JQ's limitations or age, but rather as a matter of architecture. While it's cool these days to smugly enjoy the options of vanilla JS, JQ hate was around before those standards were reliably implemented.
JQ really stepped in when dynamic web pages (i.e. pages that modify their own HTML without page refreshes) were becoming a thing. AJAX calls were new (to most) and exciting. form validations that didn't require 2-3 seconds to load, etc. All made far, far easier by the APIs JQ had.
BUT there were complications: JQ plugins meant that having multiple copies of JQ on the page tended to not work well - and that happened if you were mingling content sources. JQ didn't require it, but many coders would use the DOM to store data (JQ made it so EASY), which worked well short term but caused troubles. Example: If you have a list of items, with every other item shaded, and every item had some metadata in the HTML, and then you wanted to remove some items, what did you do? More importantly, when you wanted to restore them, where did it come from? If you were tracking everything in a JS variables and building the DOM, no problem, but if you were using the DOM to hold your data, you had issues. Even if you WEREN'T using the DOM to track your state, repainting all the DOM got expensive - a table of 10 items worked great, but a table of 1000 could bog down terribly.
Ultimately someone would inherit (or create) a convoluted mess of JQ and blame JQ rather than the creator.
Much of the JQ hate came not from JQ flaws, but the flaws of coding done in the face of JQ success (as has happened with so many languages/libraries/frameworks before and since). We've learned from those flaws AND successes though - querySelector() basically uses the sizzle syntax; modern virtual dom libraries deal with the DOM pains; be it React's Unidirectional flow or Angular's two-way binding, the goal is not to use the DOM to hold state; and every AJAX library out there tried for a better interface (arguably fetch() beat them all). We're still hashing out how to handle reusable pieces of non-static HTML, but there are many options.
So congrats to anyone that doesn't need JQ, and no hate to those that use it if they strive to use it well. I can only hope to write something hated for the results of success that nonetheless leaves the world better off.
I recently replaced jQuery on a project with a small custom DOM library. It cut more than 20% from the footprint of the application and helped to push load times on 3G under 3 seconds.
If you use some of the weirder stuff in jQuery or use plugins you might end up doing some targeted refactoring or just porting that code but I found it a relatively painless transition to make.
Tip: write unit/integration tests for the code you're about to convert as it makes the process much easier and faster.
A bit OT: In my personal projects, it's easy to use plain JS instead of jquery. But as soon as I start dealing with object- and array-data (formally json), I cannot miss the underscrore.js library. At least without it, I start writing my own helpers for some actions on obj/arrays.
[+] [-] interlocutor|7 years ago|reply
jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected'); and you don't have to check for nulls after each selection.
Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge.
For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.
[+] [-] zackbloom|7 years ago|reply
Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage.
[+] [-] Shorel|7 years ago|reply
But in this case (as in many others), code is written just a couple of times per month, and executed millions of times per day in millions of computers all around the world.
Therefore this kind of "low level JavaScript"* optimizations will have a net benefit much, much bigger than the convenience of reading shorter code for a relatively small group of people.
* Quite the contradiction, I know.
[+] [-] GlitchMr|7 years ago|reply
[+] [-] thermodynthrway|7 years ago|reply
I agree with JQuery for the most simple sites, but React+transpiler will give you much better compatibility
[+] [-] nostalgeek|7 years ago|reply
Many of these can be polyfilled, Going the polyfill route IMHO is a bit better. I use this now : https://polyfill.io .
[+] [-] Sephr|7 years ago|reply
Huh? http://youmightnotneedjquery.com/#replace_from_html and http://youmightnotneedjquery.com/#before show solutions that work in IE8+ and Edge.
[+] [-] nwienert|7 years ago|reply
Further, there are many better animation libraries.
And finally if you use any view framework you have very little need to be traversing the DOM.
[+] [-] phyzome|7 years ago|reply
But if you had a small site that just needed to perform a few DOM manipulations, this would be highly relevant. If I just need to pop a div open and closed when a button is clicked, I sure won't bring in jquery just for that.
[+] [-] Cthulhu_|7 years ago|reply
The performance question becomes a bit more tricky too then, because instead of comparing direct DOM manipulation you're comparing 'rendering' as a more abstract concept.
[+] [-] prophesi|7 years ago|reply
[+] [-] macca321|7 years ago|reply
$(document).on("click", "#foo", function(){...});
either
[+] [-] AlphaSite|7 years ago|reply
[+] [-] scns|7 years ago|reply
[+] [-] Raglov|7 years ago|reply
[+] [-] rado|7 years ago|reply
[+] [-] austincheney|7 years ago|reply
For me it has always been about performance. jQuery is slow. Even way back in the day before JavaScript got fast you could access the DOM quickly if you knew what you were doing. Likewise DOM access could easily make your code 5 times slower if you didn't know what you were doing.
Since 2012 JavaScript has been fast in every major browser and querySelectors are a standard feature. Since about that time accessing the DOM has always been 10s-100s of times faster than using the standard querySelectors. In Firefox it is 10s of thousands of times faster. The standard querySelectors are faster than using modern jQuery.
To me this is the difference between a junior developer and a competent developer. Some people NEED the extra help. I understand that. If product quality and achieving a superior user experience are important though you will simply figure out a better way of writing code, especially since writing code is probably your job.
[+] [-] jotato|7 years ago|reply
[+] [-] munchbunny|7 years ago|reply
I think it's impressive that even when I'm not using jQuery (haven't in many years), I find myself writing code using features/capabilities where jQuery was an obvious inspiration.
[+] [-] RobertRoberts|7 years ago|reply
I had used Prototype.js, and just a couple years ago finally gutted it from our code base. And shortly after started removing jQuery. It's a long slow process.
After starting with Vue.js, I completely understand why jQuery is no longer needed. Vanilla JS/CSS3 does 98% of what jQuery did for us, and our own micro-library fills in the blanks. And Vue is replacing all the jQuery scaffolded apps.
If it weren't for reactive interface libraries though, jQuery would still be a staple.
One example, I use a jQuery library for sorting tables. When I saw how sorting a table is so basically easy in Vue.js, that no plugins or 3rd party code needed, I saw the downfall of jQuery in general.
[+] [-] thrownaway954|7 years ago|reply
[+] [-] patorjk|7 years ago|reply
[+] [-] mattbierner|7 years ago|reply
[+] [-] franciscop|7 years ago|reply
And I do not always recommend it, indeed for smaller projects you might be better off with plain Javascript: https://umbrellajs.com/documentation#native-methods
But native Javascript, as explained there, is more error-prone while jQuery (and Umbrella) are more permissive. Both have their pros and cons, but if you try to make native Javascript as permissive as jQuery you'll end up with a big mess. Unless you create some internal methods, which then you bundle, test, release, and... end up with another jQuery clone!
[+] [-] Daycrawler2|7 years ago|reply
[+] [-] softwarefounder|7 years ago|reply
You'll likely start wrapping these methods, and before you know it, you have jQuery-micro.
[+] [-] infinity0|7 years ago|reply
- knows what it is, i.e. a web javascript module, it doesn't try to inappropriately wrap itself in CommonJS/AMDJS wrappers
- doesn't need node/npm to run
- doesn't need node/npm to build
[+] [-] maaaats|7 years ago|reply
[+] [-] TamDenholm|7 years ago|reply
[+] [-] topoftheforts|7 years ago|reply
[0] https://github.com/kenwheeler/cash/
[+] [-] driverdan|7 years ago|reply
[+] [-] vbezhenar|7 years ago|reply
[+] [-] SmellyGeekBoy|7 years ago|reply
[+] [-] franciscop|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] grouseway|7 years ago|reply
[+] [-] TimTheTinker|7 years ago|reply
[+] [-] dsco|7 years ago|reply
[+] [-] geuis|7 years ago|reply
[+] [-] rkuykendall-com|7 years ago|reply
They bragged, about the single worst web UI I have to use on a daily basis. Github.com combines the worst elements of static and dynamic web-pages:
- If something gets updated on the backend, it will update on the frontend
- If you change something on the frontend, it will update on the page What you end up with is a frontend that uses a lot of AJAX, but still requires constant hard refreshes to see accurate information. It's an absolute disaster.[+] [-] ape4|7 years ago|reply
[+] [-] EugeneOZ|7 years ago|reply
[+] [-] k__|7 years ago|reply
Somehow all the time I'm doing JS, people were talking about how jQuery was "an old library" and "the old way to do things" even in 2011.
2 years ago I was on a JavaScript meetup and some guy, who did interfaces for stock trading, said: "We had to write our own framework, because jQuery just didn't cut it anymore!"
I just thought, no shit, it's 2016 and NOW you talk about replacing jQuery? Since its inception I used 4 different frameworks and even when I started in 2011 it was already "old news". Where have you been living if you had the impression there is only jQuery and "your own framework"
[+] [-] juice13|7 years ago|reply
I don't see why it being old is an inherent problem.
[+] [-] ergothus|7 years ago|reply
I want to clarify a bit about "JA Hate" though: Most of it stemmed not from JQ's limitations or age, but rather as a matter of architecture. While it's cool these days to smugly enjoy the options of vanilla JS, JQ hate was around before those standards were reliably implemented.
JQ really stepped in when dynamic web pages (i.e. pages that modify their own HTML without page refreshes) were becoming a thing. AJAX calls were new (to most) and exciting. form validations that didn't require 2-3 seconds to load, etc. All made far, far easier by the APIs JQ had.
BUT there were complications: JQ plugins meant that having multiple copies of JQ on the page tended to not work well - and that happened if you were mingling content sources. JQ didn't require it, but many coders would use the DOM to store data (JQ made it so EASY), which worked well short term but caused troubles. Example: If you have a list of items, with every other item shaded, and every item had some metadata in the HTML, and then you wanted to remove some items, what did you do? More importantly, when you wanted to restore them, where did it come from? If you were tracking everything in a JS variables and building the DOM, no problem, but if you were using the DOM to hold your data, you had issues. Even if you WEREN'T using the DOM to track your state, repainting all the DOM got expensive - a table of 10 items worked great, but a table of 1000 could bog down terribly.
Ultimately someone would inherit (or create) a convoluted mess of JQ and blame JQ rather than the creator.
Much of the JQ hate came not from JQ flaws, but the flaws of coding done in the face of JQ success (as has happened with so many languages/libraries/frameworks before and since). We've learned from those flaws AND successes though - querySelector() basically uses the sizzle syntax; modern virtual dom libraries deal with the DOM pains; be it React's Unidirectional flow or Angular's two-way binding, the goal is not to use the DOM to hold state; and every AJAX library out there tried for a better interface (arguably fetch() beat them all). We're still hashing out how to handle reusable pieces of non-static HTML, but there are many options.
So congrats to anyone that doesn't need JQ, and no hate to those that use it if they strive to use it well. I can only hope to write something hated for the results of success that nonetheless leaves the world better off.
[+] [-] captain_perl|7 years ago|reply
The one feature I miss that jquery has is dialog boxes that can be customized with HTML.
Does anybody know of any cross-browser javascript dialog functions?
[+] [-] artificial|7 years ago|reply
[+] [-] rident|7 years ago|reply
If you use some of the weirder stuff in jQuery or use plugins you might end up doing some targeted refactoring or just porting that code but I found it a relatively painless transition to make.
Tip: write unit/integration tests for the code you're about to convert as it makes the process much easier and faster.
[+] [-] some1else|7 years ago|reply
Custom elements are probably a great fit for .erb templates.
[+] [-] Lurkars|7 years ago|reply