Hacker News Reader

Comment by sheetjs | Hacker News Reader

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

I understand the visceral opposition, but once you start writing a fallback to support some browser (something to support IE or FF or Safari or Chrome ...) you might as well use the battle-tested solution (and write your own thing if you find performance to be unacceptable and trace the bottleneck to jQuery)

View on HN

The question at hand is, are fallbacks necessary anymore for the browsers we are targeting today?

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?"

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

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

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.

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=querySelector

http://caniuse.com/#feat=css-transitions

http://caniuse.com/#feat=getcomputedstyle

http://kangax.github.io/es5-compat-table/#Array.prototype.fo...

Android 2.3 is the problem more than IE<9 for many developers at this point.

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.

  git fork jquery
  git branch "fix-performance-issue-at-<feature>"
  git commit ...
  git push

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.

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.

I think you need a git checkout there. ;)

I assume fork aliases to clone, which gives you a checkout.

Reply on news.ycombinator.com