3 ms·

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 w

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.
      - dmitriid 7y ago
        These things can still be designed and implemented. `element.query().<all the new apis>` for example.
  - tambourine_man 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? 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.
inimino 7y ago
TC39 has nothing to do with DOM APIs... but you're right that backward compatibility and "don't break the Web" is one of many reasons why this idea would never fly.
- vikingcaffiene 7y ago
  > TC39 has nothing to do with DOM APIs 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. :-)
  - inimino 7y ago
    W3C or WHATWG these days. One browser tries something and then another one decides to implement it, and someone writes up a spec. 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.

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.
    - dmitriid 7y ago
      These things can still be designed and implemented. `element.query().<all the new apis>` for example.
- tambourine_man 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? 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.

inimino 7y ago

TC39 has nothing to do with DOM APIs... but you're right that backward compatibility and "don't break the Web" is one of many reasons why this idea would never fly.

vikingcaffiene 7y ago
> TC39 has nothing to do with DOM APIs 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. :-)
- inimino 7y ago
  W3C or WHATWG these days. One browser tries something and then another one decides to implement it, and someone writes up a spec. 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.