> I mean, you normally abstract these things with a helper fn or two, without importing the whole jQuery anyway.
Add enough helper functions are you're at jQuery anyway. Looking at the jQuery source code, it manages a lot of edge cases that I don't really have time to figure out on my own.
The DOM API isn't really designed that well for human consumption.
> Add enough helper functions are you're at jQuery anyway.
I really hate these exaggerations. jQuery is, last I checked, over 200k unminified. Anyone writing enough helper functions to get to a fraction of that is already a pathological case.
Browsing the source of jQuery and I don't find it bloated but I find a lot of knowledge in there that a naive user the DOM API would most likely know about.
It's kind of like how you can comparing languages using simple example code isn't relevant because proper code with full error handling and edge case handling can be very different from a naive example.
The point is that this is a strawman. "Enough helper functions" to get to jQuery is 288580 bytes. A quarter of that, or even a tenth of that, is already a pathological case and way beyond almost every case of "jQuery substitution" that would happen in practice.
I could read and understand the entire jQuery source code in a single afternoon -- it's not that big. Even in the few minutes I spent reading it, I learned a few things I didn't know.
The worst thing about the web as a platform is the need to count bytes.
Once again, my friend, that's not the point, and I'm not even talking about it anywhere. I get it that you like jQuery, but your reply defending it has absolutely nothing to do with my reply.
Nobody is reimplementing the 280k of jQuery as part of their projects, so no, you won't be "at jQuery anyway". That's bullshit.
I don't like jQuery -- I mean I use it but it doesn't occupy enough brain space to even have a strong opinion on it either way. If I took jQuery out then I'd have to care more because would need to re-implement all the pieces of jQuery that my projects already use. Is that going to be 280k worth? No. Is going to be a couple of one-liners? No, because jQuery hides a lot of complexity under it's relatively simple API that take a lot of JavaScript to reproduce.
It's not crazy that to accomplish what jQuery accomplishes without jQuery you're going to need almost the same amount of code as jQuery. It's not re-implementing the DOM -- it's a pretty thin but broad wrapper. If you don't need something, remove it.
Alright, we seem to be talking past each other. Maybe that's the sign this is not a productive discussion.
I'm not calling jQuery is bloated or difficult to read, nor I am telling anyone they should count bytes.
> Is going to be a couple of one-liners? No, because jQuery hides a lot of complexity under it's relatively simple API that take a lot of JavaScript to reproduce.
> It's not crazy that to accomplish what jQuery accomplishes without jQuery you're going to need almost the same amount of code as jQuery
Once again, that's my whole point.
What I'm saying is that jQuery isn't a 100-line library. The whole of jQuery is not being trivially reimplemented at several places. Projects reimplementing portions of jQuery functionality (a la youmightnotneedjquery.com) are usually only reimplementing very very few things, and are leaving out lots of stuff. Different projects have different needs, some people don't need the whole library, some do, others don't care. That's it.
You might be right about the discussion. But I was thinking about this and I think my point comes down to the basic issue of almost every library or big piece of software. Nobody uses 100% of any big library. Nobody uses 100% of Microsoft Word. Most people use about 20%. But the problem is everyone uses a different 20% so libraries and software have a lot of features.
The argument against jQuery is thus an argument against libraries in general. Why include any dependency that you only use a small part of? You can always implement anything yourself.
The counting bytes comment is because the web, as a platform, is very size-conscious. Rarely does anyone complain about the size of libc and how, since they only use file functions, that should just call into the Linux kernel directly.
Would we even by having this discussion if you could just tree-shake out all the parts of jQuery that you never use at build time?
> The argument against jQuery is thus an argument against libraries in general.
Then it's a nice thing that I never made any argument against including jQuery or any library in a page or project, nor I'm saying anyone should reimplement it, or even do anything. I'm not talking about those things.
> Would we even by having this discussion
We aren't even having this discussion. Seems like you're having an argument against an imaginary version of me. I'm not saying (or implying) the things you are arguing against.
Your argument is that is that body is going to re-implement all of jQuery with their own helper functions. I got that. It's just not a very interesting point. Was I using hyperbole -- yes. You got me.
> Looking at the jQuery source code, it manages a lot of edge cases that I don't really have time to figure out on my own.
Reminds me of the warning about rewriting old "messy" codebases. I am paraphrasing, but the upshot was "You know what those weird and ugly bits of code are? They're bug fixes, and they were earned through sweat and blood and years over a period of many, many years."
I don't find the jQuery API to be particularly friendly. It tries to be cute and ends up being annoying. Its implementing code is also an abomination, so not particularly helpful. I'd rather read through Gecko internals than try to figure out what the hell a jQuery helper actually returns.
The DOM is at least very, very well documented. jQuery has documentation, but it's not even close. It gives away what jQuery always has been, which is a library that is aimed mainly at assisting bag-of-tricks StackOverflow programmers than people who actually want to understand their programs and the object graph they work on.
Add enough helper functions are you're at jQuery anyway. Looking at the jQuery source code, it manages a lot of edge cases that I don't really have time to figure out on my own.
The DOM API isn't really designed that well for human consumption.
https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeTy...