4 ms·

> jQuery is, among other things, an alternative DOM manipulation API built on top of native ones. So you're saying native is like an apple and jQuery is like a

> jQuery is, among other things, an alternative DOM manipulation API built on top of native ones. 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.

tambourine_man 7y ago
I was about to answer you point by point, but it's probably not much use. 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.
- inimino 7y ago
  If your argument is that the method names in DOM should be shorter, then sure, I agree. It seemed to me you were arguing for something else. 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.

tambourine_man 7y ago

I was about to answer you point by point, but it's probably not much use. 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.

inimino 7y ago
If your argument is that the method names in DOM should be shorter, then sure, I agree. It seemed to me you were arguing for something else. 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.