It’s more verbose and everybody has to relearn something they can already do in more readable and compact code.
Why haven’t they simply adopted jQuery’s APIs?
That ship has long long sailed, but still, I think we would’ve been in a much better situation right now.
This is a backwards way of looking at it. jQuery was always a convenience layer over the DOM, and the DOM and other browser APIs have undergone continuous improvement since before jQuery was even a thing.
When you say "native alternative to jQuery" it's clear that you don't understand the orders of magnitude difference in effort required between standardization and browser implementation of new APIs versus throwing a library up on github.
If browser vendors adopted jQuery APIs, you'd have a redundant DOM, incompletely implemented, with unique bugs in each browser, and probably being widely deployed just in time for React to come into fashion and make it all irrelevant.
jQuery is, among other things, an alternative DOM manipulation API built on top of native ones. And it is a better API at it. I say that because we have voted with our feet and querySelectorAll is clearly inspired by, but still a paltry copy of it.
>When you say "native alternative to jQuery" it's clear that you don't understand the orders of magnitude difference in effort required between standardization and browser implementation of new APIs versus throwing a library up on github.
I'm sorry, you are not making much sense. jQuery predates GitHub by a few years and was, at its heyday, more important than any single browser alone, I'd argue. Its API has been stable since before open web standards was a largely agreed upon thing.
>If browser vendors adopted jQuery APIs, you'd have a redundant DOM…
It wouldn't be redundant, it would be the default. I don't think you understand what I was questioning.
>…incompletely implemented, with unique bugs in each browser…
Again, not much sense. Why is implementing the current API guaranteed to be any more complete and bug free?
>…and probably being widely deployed just in time for React to come into fashion and make it all irrelevant.
From the article:
“jQuery is the most widely used JavaScript library in the world.”
“W3Techs estimates that about 74 percent of all websites use jQuery.”
So you're saying native is like an apple and jQuery is like an orange. So far so good.
> And it is a better API at it.
And now you're comparing apples and oranges.
Here's what you're missing: one guy (John Resig) implementing a library can give it a consistent UI and work through the browser incompatibility issues of the day and release something in a matter of weeks. That was enough for jQuery to find a few users and grow. No committees had to approve this. Compare any web standard, ever, with this process.
DOM came first, so it didn't benefit from hindsight, and it was designed to be consistent, sufficiently complete to eliminate non-standard APIs, and well-specified enough that all browsers could and would implement it. Test suites had to be created, each browser team had to implement these features, changes had to be made to the specs in some cases when reality diverged, and so on.
This is the orders of magnitude more effort that I'm talking about. Is the DOM a beautiful API that people love? No, it's a standard created by committees and competing vendors. It's functional, everyone eventually got behind it, and today it still works.
Without DOM and the initial W3C standardization push, there never would have been a foundation for jQuery to build on.
> jQuery predates GitHub by a few years
That's correct. This was the modern shorthand for "make it available to the world". At that time it meant registering a domain and throwing up a website. The point is: no committees.
> at its heyday, more important than any single browser alone
Apples and oranges again. Nobody has ever had the choice between using a browser on the one hand or a javascript library on the other, so I'm not sure what you're trying to say here by one being more important than the other.
> Its API has been stable since before open web standards was a largely agreed upon thing.
This is incorrect, the web standards movement was in full tilt long before jQuery (or YUI, Dojo, Mootools, etc, etc) existed. IE5 still had significant market share, but even MS at that time gave lip service to the importance of Web standards.
> It wouldn't be redundant, it would be the default.
That's not how this works. You can't remove old APIs, because the Web relies on them, so now you have two ways to do the same thing. That meets the definition of redundancy. Whether one of them is the default or not is irrelevant.
> Why is implementing the current API guaranteed to be any more complete and bug free?
It's not. The point is that, since jQuery is a library, it's free to develop workarounds for every known browser bug that affects it. If you get rid of the library and have native implementations... well now you have implementations, not one implementation. Now you need a new library to smooth over the differences.
> Please explain how that's irrelevant in any way.
Developer mindshare has moved on.
Just like COBOL, jQuery isn't going away overnight, but it would be a shame to go through tremendous effort to standardize on something that's already on the edge of obsolescence.
The argument that I've made many times in this thread is that jQuery, built through iteration, feedback loop and with the benefit of hindsight is a better API than document.querySelectorAll() et al.
And there's no reason why we couldn't have used the former instead of the latter. Why would a library to “smooth over the differences” be needed for sel(".element") and not for document.querySelectorAll(".element") ?
No one was suggesting changing document.getElementById(), etc, so nothing would break.
DOM manipulation is not going anywhere, React and friends notwithstanding.
jQuery selectors are quite a bit different from querySelectorAll, among other things, they don't return native DOM objects, but rather jQuery objects, which have bizarre and unnecessary re-implementations of things (like .each) that have not been necessary in modern JS/DOM for about ten years now, so it's not so easy as "just use jQuery, but standardize it".
If your argument was that the standardization process should have considered jQuery and other prior art, and taken good ideas from it, then of course that's exactly what happened.
- `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on`
JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
One of the reasons I like lisp-like languages more than the rest is because hyphen-separated-symbols are a lot easier to read than camelCase, which feels cramped by comparison. (underscore_separated_words is an improvement over camelCase, but for some reason people seem to shy away from it. In any event I think hyphen-separated is superior, since hyphens are used to conjoin words in English prose, while underlines typically aren't.)
It reminds me of reading 17th century dense English. I don't see how query or select is any less descriptive than querySelector.
I find that names are rarely all that useful anyway, since you can't capture the full effect of a function in a name in most cases. I once named a method mkdir() and then someone commented that it was "obscure", so it got renamed createDirectory(), then someone commented that it was actually creating all intermediate directories, so it became createDirectoryTree(). This still doesn't really communicate that it won't error if the directory already exists, so I commented it should really be createDirectoryTreeOrDoNothing().
`mkdir` is immediately obvious to someone like you or me that has a background in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system that all derives from early 70s design ethos (or hardware limitations..)) but to somebody who's not already steeped in this tradition, it's basically a bizarre incantation.
And mkdir is far from the worse of it; once you learn what it means it's easy to create a mnemonic mapping between `mkdir` and "m[a]k[e] dir[ectory]". But what about something like `ln`? Obviously that's "natural logorithm", everybody learns that in highschool. Wait no, it's not that at all. It's "[make] l[i]n[k]" Frankly, that's crap. Contrast with `make-file-or-directory-link` from racket. It means the same thing but it's more than 10x as long (less dense) and there is simply no way you could mistake that for a natural log function.
Instead, browser have two incompatible APIs: `querySelector` to retrieve one item only, and `querySelectorAll` to retrieve multiple items.
On top of that, jQuery always returns an array-like object. `querySelectorAll` returns a NodeList that is so poorly designed that it didn’t have a `.forEach` for two years or so, and you’re still better of doing an `Array.from` on it for the sake of consistency and sanity.
For every thing that jQuery got right, browsers got 10 things wrong. For every thing that jQuery got wrong, browsers got 100 things wrong. It took browsers 7 years to implement querySelector/querySelectorAll after jQuery showed it’s possible and useful. And they still got it wrong. 13 years after jQuery debuted DOM APIs are still a mishmash of extremely poorly designed functions that are unnecessarily verbose and error prone.
`querySelectorAll` doesn’t even return an array-like object. It took w3c almost two years to add a forEach to it.
It’s also so badly designed that MDN docs has a whole section oh how it behaves with unexpected results and how, quote “to restore expected behavior”.
So all perceived benefits (like the separation between Element and NodeList) are badly contrived and trumped by how badly they are designed in comparison with a 15-year old library whose core API was designed by one person.
I don't think the problem with 17th century prose is density either. Rather, it's archaic vocabulary, idioms, and grammar. I've recently been reading through an anthology of English renaissance drama and my impression is that once you become acclimatized to the common archaic vocabulary and grammar, the idioms remain as biggest impediment to understanding. Consider:
> "Art thou in thy wits? I tell thee I must have a pair of shoes; dost thou mark me? A pair of shoes, two shoes, made by this very shoe, this same shoe, against tomorrow morning by four o'clock. Dost understand me? Canst thou do't?
He's asking for a pair of shoes, and questioning whether his request is understood. It's not a particularly complex or information dense paragraph, but it could be hard to understand if all of that archaic vocabulary is obscure to you. In many ways, this makes it very similar to your average bash script. Saying something simple, but made to seem complicated by archaic terminology.
Similar in prose, if you can say it in 5 words, then why use a paragraph?
Of course, there is a sense in which lisp-like code can be dense while at the same time having verbose names for things. Consider this and an idiomatic C equivalent: (filter odd? '(1 2 3))
That is simultaneously intuitive and verbose. Would it be improved by changing `filter` to `fltr` or some nonsense like that? I don't think so. But even though it hasn't code-golf'd the names for things, it's doubtlessly shorter (denser) than the equivalent in idiomatic C using the mangled shortened identifiers that are par for the course in that language. Density through good abstractions is superior to density through short names and abbreviations.
Could you do both? Sure. But for what marginal gain?
Also some programmers opt for readabiltiy over terseness.
I've been changing my style to be more terse but that makes it more readable or easier to see the abstraction concept rather than the details.
I'd much rather read
rect = element.getBoundingClientRect()
area = rect.width * rect.height
velocity += acceleration * deltaTime
position += velocity * deltaTime
r = e.g()
a = r.w * r.h
v += a * d
p += v * d
Google, Apple, Microsoft, Facebook etc all specifically say terseness is not a goal and say to use whole words so naming a function '$' would be explicity against their guidelines. I suspect there's a reason for that. The most obvious is I don't know what 'a' or 'd' or '$' mean without digging through the code but I do know what 'area' or 'detlaTime' or 'getElementById' mean
* Variable argument types determine different kind of behavior, like ajax taking a string or object as 1st argument. Other functions take a function or string as a parameter. I'd much prefer it enforce a single style or define a new method, ajaxurl() and ajaxobj().
* naming of `off()`. In this context, off is not the opposite of on. On here means 'in event of'. A better word would be 'cancel' or 'mute' or 'ignore'.
element.on('click', dostuff);
element.ignore('click');
Doh! Yeah you are right (and I feel dumb). I suppose that would be more of a w3c/browser vendor thing wouldn't it?
Appreciate the support on the rest of it. :-)
The DOM APIs grew slowly mostly because of the general stagnation in the browser market, but they have been a long-lived, relatively successful API on which popular things like jQuery (or its competitors) could be based.
It would be insane not to. I don’t really see your point.
My point is that you simply can't do that. It would be irresponsible, short sighted, and dangerous. We are talking about a language used in nearly all of the web. The decisions that get made around it have an impact of decades. I HAS to play nice with all the prior art out there and it would be a _terrible_ decision to start adding one off handling for compatibility with libraries built atop it.
Of course not. You can implement the same API without stealing its namespace. $$, sel, select, whatever.
>Are you in all seriousness saying that a native spec should account for a library?
If it's by far the most widely used one, one that changed the way we write web apps, and made viable a whole class of solutions, then of course. That's one of the main ways platforms grow. You see how people are using it and you make it even easier, faster.
What I'm saying is, we have a half arsed copy of jQuery when we could've had the real thing, only faster and builtin.
Instead of trying some ideas in a library/framework, iterating until polished, then considering making it official, we reinvented the wheal from scratch, only, unsurprisingly, worse.
Why would it? jQuery’s APIs could be folded into HTMLElement and HTMLDocument. Instead, we’re stuck with 90s-era Java style in all the DOM APIs.