Hell yeah, you do. I just recently had to create a tiny script (one of those notorious cookie warnings) without any dependencies. It's like pulling teeth. The DOM API is an ugly, verbose mess and its pretty unbareble to use without JQuery, zepto, etc.. Including the code for parsing cookies (yeah, you still have to do that, too) the script clocked in at 318 lines of code (without comments).
With JQuery and the cookies plugin its would probably have been something like 30 lines. Thats 10 times the code you have to write, debug and maintain.
So, of course, you don't NEED JQuery just like you don't NEED any means of transportation, you can walk everywhere after all. The question is, if you want to spend you whole life walking/writing verbose ugly JS code.
I'm sorry, I really hate to be condescending. I understand there are a range of levels of JS expertise out there, and using either jQuery or an appropriate library represents real value for many.
However, when you're opening a comment with "Hell yeah, you do", I really have to respond.
Hell no, you don't. If you're writing 318 lines of code just to do a cookie warning, that's fine. But please don't preach that it's necessary before actually learning some javascript.
I'm also a bit baffled that it would take an entire 30 lines while using jQuery AND a cookie plugin. What are you doing to these cookies messages???
::EDIT::
I have no idea if the code below works, and it could do with a lot of improvement (thinking about secure cookies, cookie paths, or even just using localStorage instead), but I can't imagine a bit of testing and revision of the code would balloon it to even twice its size. Least of all 30 times its size.
(function() {
var cookiesMessage = document.getElementById('cookies-message-wrap');
var cookiesAccept = document.getElementById('cookies-accept-button');
var checkCookies = function () {
cookiesMessage.setAttribute('class', document.cookie.indexOf('cookiesaccepted=1')===-1?'':'accepted');
}
cookiesAccept .addEventListener('click', function() {
document.cookie = 'cookiesaccepted=1;expires=Tue, 19 Jan 2038 03:14:07 GMT;path=/';
checkCookies();
});
})();
I'd default the notice invisible and show it when it hasn't been accepted, rather than vice versa as you do here. That way, in the more common case, nothing needs doing. (Maybe there's a regulatory reason that won't fly? I don't know or care much beyond the obvious about the EU cookie rule.) I'd also break out some of the inlining, just to make it read more easily, if this were destined for production.
But the functionality looks good! I mean, document.cookie can be a huge pain to deal with if you actually have to deal with it, and jQuery has a plugin for that - but this doesn't take any kind of parsing, just a cheap substring check, and the class list manipulation is equally trivial. Even animation could be handled in CSS.
Perhaps OP's use case is much more complex than it sounds, in a way that's far from obvious?
I'm not sure what the regulation would say, but if I'm choosing to comply, I'm going to default to visible as absence of JS doesn't equal absence of cookies. It maybe annoying that the accept button won't work, but at least the user is informed, which I guess was the intent of the (tbh misguided) regulation.
You also got my own cookies library https://github.com/franciscop/cookies.js at 107 lines (97 LoC), with the minified+gzipped version being 846 bytes. It can be easily copy/pasted into your code if you don't want the overhead of an extra request, or just using unpkg CDN:
As a long time JavaScript developer jQuery feels like welfare. You can absolutely live without it. Living without it means you will find ways to perform better. For people who have never lived without it the world is a scary place. God forbid anybody suggest an alternative to an entitlement.
- "finding ways to perform better" by living without it is not something that happens in real life. To the contrary, living without adequate financial support has been shown by many studies to lead to anxiety, mental issues and general under-performance.
- It's clearly an unnecessary and disingenuous attempt to bring a loaded political agenda of your own into an otherwise innocuous discussion of programming libraries.
Again, I believe your opinions on this matter absolutely reinforce the analogy.
I can say this with clarity and objectivity because I have had to rely on government handouts a long time ago when I had my first kiddo while being an unemployed college student only to drop out of school and work below the poverty line. Some people can figure it out and others cannot. The embarrassment and offense are very much a part of that issue as well as the imposter syndrome that is so obvious in so many developers.
Citing an anecdote (albeit your own) doesn't make you objective. I've been through the (actually exact, by your description) same experience and I'm doing fine but that doesn't translate to the generality in any way.
On the matter of objectivity let's examine the issue and follow it through:
A comment is made that correlates a popular technology opinion to a dreadful political subject. Offense ensues. Next... sadness.
A couple of months ago I heard the most perfect description for such a sentiment from an army colonel to which he described such (in a broader context) as fragility. Sadness is not a valid qualifier for making a rational qualification of competencies... except in software where imposter syndrome is rampant.
I will stop here. I have had this conversation numerous times in the past and for people who suffer from fragility it is generally not understandable beyond an honest disclosure of what it really is. To me welfare is the perfect analogy. For people addicted to that system no rational conversation will convince them double the work in the short term could have 10x benefits later down the road. They can't see it and don't want it. They are content and utterly reliant upon the tools provided to them.
I really don't get this vendetta some small number of people seem to have against jQuery. It seems like it gets looked down upon in the same way that PHP gets looked down upon. But while PHP has legitimate problems most arguments against jQuery seem to boil down to "You can save a 100k download!".
I mean, 100kb is a big deal when it stops the page rendering, especially on mobile. But jQuery is not 100kb, it's 32kb when gzipped and minified.
I think a better sentiment is that you probably don't need jQuery. jQuery is a great library, but with the modern state of JS, you can probably get by without it and spend that 32kb on something else more useful.
You can get Preact, RxJS-lite and Immutable in total for about 40kb - is that going to be a better use of your performance budget?
And if you're doing it right, it's not even 32kb because chances are your visitor already has it cached in their browser even before visiting your site.
1. Your visitor must have visited other sites using jQuery from a CDN.
2. One of those sites must have used the same CDN you're using.
3. The site must have used the exact same version you're using.
4. Depending on the CDN, the version must have been served from the same URL (e.g. a problem when CDNs allow specifying partial version numbers and sites differ between referencing the full version number or just a part of it, 1.8 vs 1.8.2).
And you're already doing things right, using HTTP/2 and everything, but your client hasn't visited a site before that uses your CDN and your version via your URL, now what? Your visitor's browser has to make another DNS lookup, open another connection to a different server, possible block your own scripts from executing because they depend on jQuery, and so forth.
But if you're doing it right and using HTTP/2 and everything and hosting jQuery yourself (or possibly even use a vendor bundle) there won't be any visitors who have already got your jQuery version cached but the browser can avoid the overhead of another DNS lookup and another connection and just tell the server to send jQuery along with everything else over the same socket.
Public CDNs have been of questionable value from the start[0] but with HTTP/2 this "if you're doing it right, you're loading your dependencies from a public CDN" meme needs to finally die.
[0]: AFAIK the argument that public CDNs are a performance gain for third-party dependencies (vs bundling and/or hosting them yourself) was never substantiated with any real-world data. I guess for jQuery things have improved a bit with jQuery providing an official CDN as the default option but this doesn't help with jQuery plugins or anything other than jQuery itself.
So even with today's browser and JavaScript improvements that 20kb should still be avoided if possible. Why?
- Each file downloaded adds latency. This especially hurts if you're on a satellite or similar, highly latent connection. The more files you have to download the worse start-up and various loading timing can get.
- Okay, so let's say you minified and combined everything to help avoid the first issue, now you have a new issue: all JavaScript needs to get executed when included. So adding 20kb worth of JavaScript, while not all of it is executed immediately, a chunk of it is. This adds to start-up time.
- Don't forget JavaScript execution, when compared to a desktop, is absolutely abysmal. For mobile web browsers you need to shave as much time off of start-up and ready states as possible.
I don't know, man. The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size. If that means that some random satellite user has to wait 101s instead of 100, so be it. To me, that's much ado about nothing.
jQuery is also not doing a whole lot on startup, its functions get called when needed. Lodash is the same.
> The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size.
2.5MB is absolutely ridiculous. Regardless, you just created a straw-man. jQuery is, what, 26kb minified + gzipped? So you could also say that if website is 100kb then jQuery is 25% the size of your website.
Now 26kb is not much at all but small things add up very quickly. If you're not using it, don't include it. If you can write a tiny bit of extra code to avoid a dependency that isn't highly specialized (e.g. moment.js) it's usually a good idea on the web.
> If that means that some random satellite user has to wait 101s instead of 100
FYI satellite connection issues are more about latency than bandwidth. Adding an extra connection (if it's not concatenated) to fetch jQuery can easily add more than 1 second even though it's only 26kb. Also, I sure hope your app doesn't take 100 seconds to start-up :)
A satellite connection is an example of a highly latent connection. I've seen issues which have caused all sorts of other types of connections to spike with high latency. It's important, in my opinion, for your site to be able to handle that (and honestly it's not that hard).
Satellite in a bit of a red herring in terms of the point I wanted to convey.
I also spent about 3 years working on systems that had to work across satellite connections so I have a little bias as well :)
It claims that because there is direct access to all the DOM API, you really don't need jQuery, but then it gives examples on how simple jQuery calls maps to different, multimethod calls to the DOM API. Those examples show how jQuery provide a nice abstraction on top of the DOM.
This article is like saying, we don't need high-level languages because we can all learn assembler.
I think people are reading too much into the intent of this. "You Don't Need jQuery" is in no way the same as saying "Don't Use jQuery".
jQuery is a convenient abstraction on more verbose DOM APIs. Using it makes development quicker and easier. Here is an educational article demonstrating what those DOM APIs look like to many who may have opted to take the quicker & easier route of learning jQuery without learning DOM.
A lot of the animation examples are actually quite different in subtle ways.. Eg. the fade out example using opacity with CSS animations - the element still remains in the DOM.
This is exactly what I came here to type. Or, you can take all the vanilla js snippets, wrap them into a shorter notation... and build your own jQuery, just with less portability. I don't get the point of this.
JQuery is massive and has a lot of functionality. Sometimes this is nice, but sometimes all you need from it is a small part of that whole. I think the point of that link is that if you are looking to build in some simple functionality like hide and show an element when someone clicks a button, then you do not really need to include the whole JQuery library just to do that because then the massive library is not being used and you would be better served to write your own vanilla function.
I don't see anything wrong with that. No one is saying that JQuery sucks or that it should die, I think the point is more "use the best tool for the job".
You can buy a massive wrench with all kinds of adjustable settings and addons and stuff but if all you ever need is an Alan key, then maybe the little one that comes with your IKEA furniture is actually better and easier to use than that massive wrench.
4. Switch of though-process ( jQuery, although quite flexible ), makes you think that everything is "string", "array", "object" and sometimes you need the bare Node-element e.g. https://developer.mozilla.org/en-US/docs/Web/API/Element
Obviously you don't need jQuery, and twiddling in the DOM for an Angular app means you are doing something wrong.
However, jQuery is still quite useful and I include it in most projects. It makes various tasks, like event handling, AJAX requests and minor DOM tweaks, quite a bit nicer. Zepto is a good alternative with an almost-compatible API (http://zeptojs.com). I would rather generally that developers used these off-the-shelf tools instead of implementing possibly buggy versions of functions like `height()`!
Though I've been using it less and less with the rise and convenience of vdoms, I always found that the most useful and delightful bit of jQuery is its treatment of nodesets as proper ordered sets, and that many of its manipulatory methods properly work on sets.
[].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work
as they should. I don't know why that method doesn't just return an array to begin with, but this is how you get one from it.
> on which all of the language's sequence manipulatory methods work as they should.
Which is significantly less convenient and readable than using set-operatic traversal and manipulation functions:
$('div').prev()
will give me the preceding sibling of every div in the page, in native, best case scenario using ES2015 arrow functions and Array.from it's something like this:
jQuery works on and manipulates node sets, and I find that to be a beautiful and convenient abstraction. I expect that is not unlike the satisfaction users of APL or its descendants feel (although I can't for the life of me get beyond their sigil soup).
I don't really have a positive counter-argument for this claim.
The closest I can come is that, while the latter two examples are indeed more verbose, they're not really unattractive in their own right, and they do have the virtue of explicitude which jQuery's set operations, while conceptually clean and syntactically concise, lack. If you're not closely familiar with jQuery - which I no longer am, having touched it barely at all for better than half a decade now - what comes back from
$('div').prev()
isn't obvious. It probably requires experimentation in the console or a documentation review to be clear on the return value - and jQuery's documentation is, to be charitable, not of the most lucid.
Meanwhile, in either of the native ES examples, it is immediately clear what's going on, albeit at the cost of additional verbosity: you're getting a set of elements, mapping each to its prior sibling, and filtering out those whose lack of a prior sibling resulted in a meaningless value in the map. (To this point, in ES5, I would instead write .filter(function(e) { return e !== null; }); the Boolean constructor is a useful shorthand, but shares the jQuery property of lacking lucidity.)
In a team with deep enough experience of jQuery that the meaning of your first example would be clear to anyone working on the code, I wouldn't object to writing it that way. In any other context, and especially on a team with widely varying levels of skill and experience not just with jQuery but with relevant concepts in general, I would strongly favor the more verbose examples, both because they're easier to follow from scratch in their own right, and because they serve as complete examples of a pattern with applications far beyond the realm of DOM manipulation and thus have value beyond there mere convenience to type.
> [].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work as they should.
While true it's important to remember this creates a new, shallow array copy. It's not something you'd want to call often.
Also it may be better to use Array.prototype.slice.call instead to avoid the extra, empty array instance your shortcut creates. How much better is likely insignificant, however; it's mostly a personal preference of mine :)
> I don't know why that method doesn't just return an array to begin with, but this is how you get one from it.
That's a fair point about garbage creation; I wouldn't do that in a tight inner loop, either. And now I know why that method doesn't just return an array to begin with. Thanks!
I don't quite understand why browser vendors haven't developed a terse, fluid API similar to jQuery/zepto with a touch of underscore/lodash and standardized on it. Not only would this be easier to code to, but the JS runtime should have some opportunities optimizing chained function calls to the DOM.
10y after release, jQuery is an established pseudo-standard that is not going away any time soon. Even with querySelector/querySelectorAll/getElementsByTagName/getElementsByClassName, I am still using jQ as the vanillaJs API feels so clunky and verbose.
While I'm firmly of the opinion that full jQuery is a fine choice for most projects, if you don't need `$.animate` or favour fetch over `$.ajax` you might be better-served choosing the slim build or smaller libraries that provide only a subset of jQuery's functionality (Domtastic, Zepto, etc)
While I don't agree that eliminating JQuery is necessarily something to strive for, I do like to see these sorts of projects because they help me learn how to reduce my dependency on jQuery when it makes sense to
For example, there are new native language features in ES6 that make little utility functions like $.inArray obsolete.
I used http://youmightnotneedjquery.com/ a lot when I was trying to wean myself off mental jQuery dependencies. It's nice to know that there are some alternatives too.
If you miss the $ function for DOM element selection, it's pretty trivial to wrap querySelectorAll in your own one-line helper function.
The only future proof form of web development is being able to write things natively. Everyone gets pissy when you show that maybe their preferred framework or library isn't needed because that means their way of doing things might be replaced. But native code doesn't give a damn.
Note: you can use `querySelector` on elements other than the root element. This can be helpful if you need to use React's `ref` escape hatch to do something "low-level".
I love these sorts of comparisons. For years I was working with and around jQuery code and coders, and no matter how much I tired, I could just never learn jQuery. It felt too high level, like a world built out of train tracks, so instead of going directly from point A to point B you took the 'easy' route that quickly takes you from A to C with no traffic, how fast was that? To D, then D in such a simp,e and easy way. Then finally maybe end up at our destination.
It wasn't until I resolved to try to learn JavaScript without jQuery at all that that mental barrier preventing me from understanding was removed. I blame the abstraction level and omnipresence of jQuery for preventing me from being able to learn JavaScript.
Now Ive been writing vanilla JS for a couple of years, a, learning s lot, and I gain a lot of knowledge from posts like this, Ditching jQuery, and YouMightNotNeedJquery, not because I knew the jQuery way—just because they lay out the simple JS way to do common things.
Long story short, after starting to learn JS I still cant figure out what a block of jQuery code is doing unless i re-implement it as vanilla to check and see if my guess is correct. I cant wait for the day when people are content with browser APIs for these things, many are simple but much more flexible.
One can drive automatic (jquery - no worry of browser issues) or stick shift (native - test in all browsers of all types for everything). In most cases you prefer automatic but sometimes you need stick shift when you go off-roading. If others have to drive, automatic is still probably better.
When on a team it is good to use a common library that is tested across all browsers and does native calls encapsulated within it. When working on an app the last thing you usually want to get caught up on is browser inconsistencies that are easily avoidable, wasting time on that when not necessarily needed for that project. Other times you might need to go off-roading. If you always offroad though because you just hate automatic, well you won't be drinking coffee or using your phone much, you'll be worrying about shifting.
I wouldn't mind a smaller version of jQuery, I've heard of some, I've also tried min/slim versions.
Still including a 200+kb file for jQuery... to just use well these are the most common ones I use:
var targ = $("#targ");
targ.show,.hide,.val(),.text(),.css,.post(),.done,.promise(),.each(),.remove(),.on('blur" or .on({ blur: mouseup, .height(), .width(), .scrollTop(), etc...
Probably much more, yeah certainly shorter code, gotten used to using it.
edit: At this time I always build with jQuery, always include it in the <head> section. Could wait if it's a potential thing to slow down loading of site but I usually just have a copy on my server.
Hm, over here, the 3.2-version of jQuery comes in as something like 85Kb, 323Kb when zipped. The slim build under 70Kb and compressed it's something like 20Kb. And there's zepto which comes in at around 10Kb.
Haven't heard of Zepto. Will check that out. I realize too that ~70KB is not bad really. But I was working on a site for a client where their internet speed is 0.3Mbps and a ~300KB file was taking ~300ms+ to load. No maybe more than that actually(can't recall right now). 1KB files were taking a second to load. I don't know, had to figure out a closer data center and change the site a lot with how it loaded stuff.
FWIW while gzipped sizes are more interesting for network performance, non-gzipped sizes give a better approximation for parsing times, which can be significant on low-powered mobile devices.
My view on this is that if you are going to take advantage of the extended list of jQuery plugins out there then you should definitely use it. But if you are just using it to make your own changes to DOM then just use native JS.
jQuery plugins have come to my rescue many times in tight production deadlines. The options out there, and generosity of developers to give away and keep updated in response to demands, is first class.
jQuery by itself is something which is just nice to know is there, for quick DOM manipulation in the standard way you know how, and other devs know how. Hassle-free and accessible.
As a jQuery fan I'm glad there's more tools and methods out there, however. I'm keen on VueJS myself but not yet confident. I'll be avoiding React and Angular because to me they feel like using an industrial lathe when all you need is a Dremel.
Performance crumbling is still more likely to be caused not by choice of JS library, but shoving too much content down the throat of users because you as developer couldn't say no, or when you advised against it were ignored.
I actually tried using plain JS in recent projects of mine , here`s my take .
If it is a simple 3-4 page website I write it in plain JS , if it is a complex website with lots of views and components I write in Vue + plain JS (if req).
This is hilarious. I mean, relying on external libraries aside, just look at the readability and intuitiveness of the native syntax by comparison. It's not even close.
With JQuery and the cookies plugin its would probably have been something like 30 lines. Thats 10 times the code you have to write, debug and maintain.
So, of course, you don't NEED JQuery just like you don't NEED any means of transportation, you can walk everywhere after all. The question is, if you want to spend you whole life walking/writing verbose ugly JS code.