5 ms·

Greenspun's Tenth, updated for 2014: "Any sufficiently complicated website contains an ad-hoc, informally-specified bug-ridden slow implementation of half of jQ

• sfeng 13y ago
  The question at hand is, are fallbacks necessary anymore for the browsers we are targeting today?
  • __david__ 13y ago
    And the followup is, when do you remove fallbacks from your code? Every time I think I should remove something I end up thinking, "well, it still works just fine, does it really matter if it stays for a little longer?"
    • nostrademons 13y ago
      The cost is in latency and complexity for users of your head browsers. How much do you want to reduce the user experience of your users on modern browsers to support users on old ones? There isn't a one-size-fits-all answer for this, but you should have some idea of what your traffic breakdown by browser is, and ideally what your cost in conversion rate is for each additional ms of latency (this varies by industry). I don't remember offhand what the cost per byte in latency is, but IIRC we measured something like 1ms per 1K bytes at Google (this would work out to a 1 MBps = 10Mbps connection, which seems around right for typical cable/residential fiber households these days).
      • __david__ 13y ago
        I'm not sure what you mean about "complexity for users of your head browsers". The idea of the fallback/polyfill is that it doesn't even come into effect for the modern browsers. As far as latency is concerned, I hear you and that makes sense, but the things I'm talking about are not very big, so the latency gain isn't going to matter much for our purposes. Yeah, we definitely look at the analytics. But even if it the old browser users are sub 1 percentage point, I see the number and think, "I could take this 5 line polyfill out, but then these 1000 uniques wouldn't work." And I just don't have the heart...
        • nostrademons 13y ago
          Polyfills are generally a good idea - they cost basically nothing for users of modern browsers, and they go away. I thought that the issue in this thread is JQuery, which is a layer on top of the modern browser API (probably because the modern browser API didn't exist when it was created, and is in a large part a native implementation of JQuery functionality), and so incurs the cost of all its legacy compatibility support even if you don't need it.
  • nostrademons 13y ago
    And the answer to that is: generally not for IE 10 & above. Sometimes for IE9. Often for IE8. Take a look at the caniuse tables for common functionality in JQuery: http://caniuse.com/#search=classList http://caniuse.com/#search=classList http://caniuse.com/#search=querySelector http://caniuse.com/#search=querySelector http://caniuse.com/#feat=css-transitions http://caniuse.com/#feat=css-transitions http://caniuse.com/#feat=getcomputedstyle http://caniuse.com/#feat=getcomputedstyle http://kangax.github.io/es5-compat-table/#Array.prototype.forEach http://kangax.github.io/es5-compat-table/#Array.prototype.fo...
  • dmethvin 13y ago
    Android 2.3 is the problem more than IE<9 for many developers at this point.
  • smrtinsert 13y ago
    Oh I see. Yeah you can just include a badge at the bottom right "Best used/viewed on Mac Firefox or Chrome". For anyone else, just use jQuery.
• _lce0 13y ago
  git fork jquery git branch "fix-performance-issue-at-<feature>" git commit ... git push
  • EpicEng 13y ago
    Rarely that easy. Oftentimes a performance issue can be traced back to an implementation that must support a dizzying array of use cases. You may not need all of that, but you certainly cannot just tear it out and push it back up.
    • smileysteve 13y ago
      You make another great point. Jquery includes tests for its implementations. When you improve a slow implementation, it should be tested against that existing dizzying array of use cases.
  • smtddr 13y ago
    I think you need a git checkout there. ;)
    • Dylan16807 13y ago
      I assume fork aliases to clone, which gives you a checkout.