12 ms·

I never understood why browser vendors went to the trouble of agreeing on and creating a native alternative to jQuery. It’s more verbose and everybody has to r

I never understood why browser vendors went to the trouble of agreeing on and creating a native alternative to jQuery. 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.

rmilejczz 7y ago
Edit: I misinterpreted parent comment, please disregard
- flatline 7y ago
  The implementation is largely independent of the API. A native jquery implementation could be just as performant as the standard query methods on document.
  - rmilejczz 7y ago
    Perhaps I misunderstood the original comment, seemed like they meant implementing identical APIs to jQuery, I thought they meant simply writing an abstraction in JS (I.e. not a native impl). That’s my bad
charrondev 7y ago
I appreciate the clearer naming of the built in methods. - `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.
- tambourine_man 7y ago
  I hate the verbosity of it. The “fun” part of jQuery is important to its success.
  - greggman2 7y ago
    You can repo the shortness with a few tiny functions you put in your own library. Probably less than 1k vs all of query. Also some programmers opt for readabiltiy over terseness.
    - wolco 7y ago
      Maybe it's just me but the terseness is beautiful. 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.
      - greggman2 7y ago
        > terseness is beautiful. I'd much rather read rect = element.getBoundingClientRect() area = rect.width * rect.height velocity += acceleration * deltaTime position += velocity * deltaTime than r = e.g() a = r.w * r.h v += a * d p += v * d but to each their own. 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
  - krispbyte 7y ago
    I hate the "fun" of debugging jQuery. I'd rather have a plain boring easy api.
    - dsego 7y ago
      What's there to debug?
  - partialrecall 7y ago
    Personally I don't see the problem with code that's verbose in this manner. If the right names for things are chosen then the code written with those names will read like prose, which makes it pleasant for a programmer and approachable for a self-styled non-programmer. And it's not like it's much more typing, what with modern completion systems in modern text editors... 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.)
- greggman2 7y ago
  "this" is also set by native listeners. IIRC it's the elem the event was added to where as event.target is the element that the event was cause from (often not the same). Example: https://jsfiddle.net/greggman/qpb7ct15/ https://jsfiddle.net/greggman/qpb7ct15/
- libria 7y ago
  The biggest irritations for me: * 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'); off('click')/off('mouseover') sounds like if you click/hover off the dialog box which is incorrect.
vikingcaffiene 7y ago
The reason they didn't adopt jQuerys API's is because TC39 has a rule to always be backwards compatible. See the flat map/smoosh controversy to get an idea of what I mean. Every decision that gets made by that group is designed to that end. If they adopted jQuery's api's it would break 70%+ of the web. It would be a total shit show to put it lightly. Think about how tangled up and hard to change the average jQuery site is. No, they can't do that.
- tambourine_man 7y ago
  It’s entirely possible to create a native implementation of jQuery without breaking compatibility with it. It would be insane not to. I don’t really see your point.
  - vikingcaffiene 7y ago
    Are you are suggesting that they make a spec that implements API's that would conflict with 70%+ of the web and they deal with those conflicts by adding a `if (window.jQuery) return;` in all those calls? Are you in all seriousness saying that a native spec should account for a library? 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.
    - dmitriid 7y ago
      > make a spec that implements API's that would conflict with 70%+ of the web 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.
      - vikingcaffiene 7y ago
        I want to be clear here: its totally possible to implement jQuery's api's in the native spec. That's not the part that makes doing so irresponsible and dangerous. Its the fact that (to use a trivial example) `$('.thing-i-want').click(doSomething)` implemented on an existing site would now potentially behave differently when the new spec got released. Worse, it might not break outright and instead cause a bunch of confusing errors that you gotta trace back to the source. Now scale that out to web scale, add it to every jquery version and api out there that conflicts. Think about all the little mom and pop wordpress sites that don't have a staff of developers on hand to scramble and address the litany of bugs that would cascade down upon them. The web would go up in flames.
goto11 7y ago
The primary benefit of jQuery was to provide a compatibility layer on top of the bugs, omissions and and inconsistencies in the browsers implementations of the standards. The solution here is for the browsers to iron out these issues, not to provide a brand new API for ding the same things which would probably have the same amount of issues.
inimino 7y ago
> 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.

rmilejczz 7y ago

Edit: I misinterpreted parent comment, please disregard

flatline 7y ago
The implementation is largely independent of the API. A native jquery implementation could be just as performant as the standard query methods on document.
- rmilejczz 7y ago
  Perhaps I misunderstood the original comment, seemed like they meant implementing identical APIs to jQuery, I thought they meant simply writing an abstraction in JS (I.e. not a native impl). That’s my bad

charrondev 7y ago

I appreciate the clearer naming of the built in methods. - `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.

tambourine_man 7y ago
I hate the verbosity of it. The “fun” part of jQuery is important to its success.
- greggman2 7y ago
  You can repo the shortness with a few tiny functions you put in your own library. Probably less than 1k vs all of query. Also some programmers opt for readabiltiy over terseness.
  - wolco 7y ago
    Maybe it's just me but the terseness is beautiful. 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.
    - greggman2 7y ago
      > terseness is beautiful. I'd much rather read rect = element.getBoundingClientRect() area = rect.width * rect.height velocity += acceleration * deltaTime position += velocity * deltaTime than r = e.g() a = r.w * r.h v += a * d p += v * d but to each their own. 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
- krispbyte 7y ago
  I hate the "fun" of debugging jQuery. I'd rather have a plain boring easy api.
  - dsego 7y ago
    What's there to debug?
- partialrecall 7y ago
  Personally I don't see the problem with code that's verbose in this manner. If the right names for things are chosen then the code written with those names will read like prose, which makes it pleasant for a programmer and approachable for a self-styled non-programmer. And it's not like it's much more typing, what with modern completion systems in modern text editors... 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.)
greggman2 7y ago
"this" is also set by native listeners. IIRC it's the elem the event was added to where as event.target is the element that the event was cause from (often not the same). Example: https://jsfiddle.net/greggman/qpb7ct15/ https://jsfiddle.net/greggman/qpb7ct15/
libria 7y ago
The biggest irritations for me: * 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'); off('click')/off('mouseover') sounds like if you click/hover off the dialog box which is incorrect.

vikingcaffiene 7y ago

The reason they didn't adopt jQuerys API's is because TC39 has a rule to always be backwards compatible. See the flat map/smoosh controversy to get an idea of what I mean. Every decision that gets made by that group is designed to that end. If they adopted jQuery's api's it would break 70%+ of the web. It would be a total shit show to put it lightly. Think about how tangled up and hard to change the average jQuery site is. No, they can't do that.

tambourine_man 7y ago
It’s entirely possible to create a native implementation of jQuery without breaking compatibility with it. It would be insane not to. I don’t really see your point.
- vikingcaffiene 7y ago
  Are you are suggesting that they make a spec that implements API's that would conflict with 70%+ of the web and they deal with those conflicts by adding a `if (window.jQuery) return;` in all those calls? Are you in all seriousness saying that a native spec should account for a library? 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.
  - dmitriid 7y ago
    > make a spec that implements API's that would conflict with 70%+ of the web 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.
    - vikingcaffiene 7y ago
      I want to be clear here: its totally possible to implement jQuery's api's in the native spec. That's not the part that makes doing so irresponsible and dangerous. Its the fact that (to use a trivial example) `$('.thing-i-want').click(doSomething)` implemented on an existing site would now potentially behave differently when the new spec got released. Worse, it might not break outright and instead cause a bunch of confusing errors that you gotta trace back to the source. Now scale that out to web scale, add it to every jquery version and api out there that conflicts. Think about all the little mom and pop wordpress sites that don't have a staff of developers on hand to scramble and address the litany of bugs that would cascade down upon them. The web would go up in flames.

goto11 7y ago

The primary benefit of jQuery was to provide a compatibility layer on top of the bugs, omissions and and inconsistencies in the browsers implementations of the standards. The solution here is for the browsers to iron out these issues, not to provide a brand new API for ding the same things which would probably have the same amount of issues.

inimino 7y ago

> 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.