17 ms·

> agreeing on and creating a native alternative to jQuery This is a backwards way of looking at it. jQuery was always a convenience layer over the DOM, and the

> agreeing on and creating a native alternative to jQuery 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.

tambourine_man 7y ago
>jQuery was always a convenience layer over the DOM 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.” Please explain how that's irrelevant in any way.
- inimino 7y ago
  > 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

>jQuery was always a convenience layer over the DOM 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.” Please explain how that's irrelevant in any way.

inimino 7y ago
> 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.