5 ms·

Fantastic point. Abstractions can be dangerous because they often aren't developed right. But that isn't the case here. When something like jQuery comes along

by chavesn 13y ago

Fantastic point. Abstractions can be dangerous because they often aren't developed right. But that isn't the case here. When something like jQuery comes along, hiding so many gory details, and has been tested to death both in development and in production use all over the world, we are all better off because we remove so much failure surface area from our code.

sfeng 13y ago
The question is, how many of those gory details still exist in modern browsers? There's not much to test if you're just calling el.classList.add().
- tghw 13y ago
  Define "modern"? IE8? Older Android browsers? How much compatibility are you willing to give up?
- dmethvin 13y ago
  More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
  - wyuenho 13y ago
    A classList polyfill is like 500b compressed. No need to blow a non-existent problem out of proportion. https://github.com/remy/polyfills/blob/master/classList.js https://github.com/remy/polyfills/blob/master/classList.js
    - kayoone 13y ago
      are you serious ? thats actually a good example on why you should use jquery. First of all the dev needs to know exactly on which platforms he will run into problems and how to solve them...And what if you need not one but several polyfills ? That gets messy pretty quickly.
      - wyuenho 13y ago
        Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than jQuery? Bring them in too. There are asset pipelines and/or pure front end packaging solutions like AMD to help you. What's the problem?
        lmm 13y ago
        > You should always know what browser feature you are using. Why? If I just drop jQuery in and treat that as my API baseline, what do I lose? A little performance, a few hundred kilobytes' download (almost certainly cached from a CDN anyway). And it frees me up from remembering a bunch of corner cases and keeping track of a bunch of implementation details, letting me focus my attention on more important things.
        wyuenho 13y ago
        The point is, jQuery doesn't free you up from remembering lower level details, they are still there in your face all the time, especially when it comes to event delegation and handling. jQuery also doesn't help you with CSS, which is even more of a pain than DOM inconsistencies. The whole point of polyfills is to patch browser incompatibilities, often times without losing any performance to newer browsers, so you can provide the best experience to half the people in the world on newer browsers and a mediocre experience to the rest, instead of a mediocre experience for everyone. If you care about attention to details, you should understand what your browser is doing. Polyfills are things that you only have to learn once and drop in once. Isn't providing a good experience one of the more important things?
        talmand 13y ago
        Actually, jQuery can help with CSS inconsistencies, much the same way vanilla Javascript can, if you have the mind to use it that way. You seem to be laying much of the "mediocre experience" on jQuery in this case. I would like to know why you feel this way. Seems to me that loading in polyfills for every browser inconsistency can lead you to the same problems you feel exist with jQuery. I don't just care what my browser is doing, I care what all of them are doing; which often leads to using jQuery. Depends on the project and the number of expected browsers involved. Polyfills are things you learn once and drop in once? So is jQuery. What if the best experience to be provided suggests using jQuery? Would you use it? All in all, to use or not use jQuery often depends on the project. If it fits, use it; if it doesn't, don't use it.
    - rwaldron 13y ago
      ...Which is an argument in _favor_ of jQuery. You silly goose!
- Jakob 13y ago
  And style.display='block' for jQuery.show() does not work with <tr>'s (which need 'inline-block') and rules which have an !important clause in the CSS (which need to first set the display to empty string and then set it again).
diminish 13y ago
Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.
- nswanberg 13y ago
  http://www.quora.com/JavaScript-programming-language/If-a-browser-built-in-jQuery-natively-would-it-speed-things-up?share=1 http://www.quora.com/JavaScript-programming-language/If-a-br...
- jerf 13y ago
  As near as I can tell, browsers are already at least sometimes caching compiled representations of JS; the win from shipping specific versions of jQuery would be minimal, and not work unless you used specific CDNs anyhow.

by chavesn 13y ago

sfeng 13y ago

The question is, how many of those gory details still exist in modern browsers? There's not much to test if you're just calling el.classList.add().

tghw 13y ago
Define "modern"? IE8? Older Android browsers? How much compatibility are you willing to give up?
dmethvin 13y ago
More to test than you thought. That just broke more than 20% of the Android installed base, since Android 2.3 doesn't work with classList.
- wyuenho 13y ago
  A classList polyfill is like 500b compressed. No need to blow a non-existent problem out of proportion. https://github.com/remy/polyfills/blob/master/classList.js https://github.com/remy/polyfills/blob/master/classList.js
  - kayoone 13y ago
    are you serious ? thats actually a good example on why you should use jquery. First of all the dev needs to know exactly on which platforms he will run into problems and how to solve them...And what if you need not one but several polyfills ? That gets messy pretty quickly.
    - wyuenho 13y ago
      Ah no. First of all, you should always know which platform you target and what works and what don't work on those platforms, even if you are using jQuery. jQuery is not perfect. Platform specific corner cases are still exposed to you. What if you need several polyfills? Drop them in too. You should always know what browser feature you are using. The same argument goes for using libraries. What if you need more than jQuery? Bring them in too. There are asset pipelines and/or pure front end packaging solutions like AMD to help you. What's the problem?
      - lmm 13y ago
        > You should always know what browser feature you are using. Why? If I just drop jQuery in and treat that as my API baseline, what do I lose? A little performance, a few hundred kilobytes' download (almost certainly cached from a CDN anyway). And it frees me up from remembering a bunch of corner cases and keeping track of a bunch of implementation details, letting me focus my attention on more important things.
        wyuenho 13y ago
        The point is, jQuery doesn't free you up from remembering lower level details, they are still there in your face all the time, especially when it comes to event delegation and handling. jQuery also doesn't help you with CSS, which is even more of a pain than DOM inconsistencies. The whole point of polyfills is to patch browser incompatibilities, often times without losing any performance to newer browsers, so you can provide the best experience to half the people in the world on newer browsers and a mediocre experience to the rest, instead of a mediocre experience for everyone. If you care about attention to details, you should understand what your browser is doing. Polyfills are things that you only have to learn once and drop in once. Isn't providing a good experience one of the more important things?
        talmand 13y ago
        Actually, jQuery can help with CSS inconsistencies, much the same way vanilla Javascript can, if you have the mind to use it that way. You seem to be laying much of the "mediocre experience" on jQuery in this case. I would like to know why you feel this way. Seems to me that loading in polyfills for every browser inconsistency can lead you to the same problems you feel exist with jQuery. I don't just care what my browser is doing, I care what all of them are doing; which often leads to using jQuery. Depends on the project and the number of expected browsers involved. Polyfills are things you learn once and drop in once? So is jQuery. What if the best experience to be provided suggests using jQuery? Would you use it? All in all, to use or not use jQuery often depends on the project. If it fits, use it; if it doesn't, don't use it.
  - rwaldron 13y ago
    ...Which is an argument in _favor_ of jQuery. You silly goose!
Jakob 13y ago
And style.display='block' for jQuery.show() does not work with <tr>'s (which need 'inline-block') and rules which have an !important clause in the CSS (which need to first set the display to empty string and then set it again).

diminish 13y ago

Browsers of the world, please embed, compile and cache last few versions of JQuery upfront. That's gonna speed up the whole navigation experience.

nswanberg 13y ago
http://www.quora.com/JavaScript-programming-language/If-a-browser-built-in-jQuery-natively-would-it-speed-things-up?share=1 http://www.quora.com/JavaScript-programming-language/If-a-br...
jerf 13y ago
As near as I can tell, browsers are already at least sometimes caching compiled representations of JS; the win from shipping specific versions of jQuery would be minimal, and not work unless you used specific CDNs anyhow.