Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cut support for IE6-8 and other older browsers. #943

Closed
jdalton opened this issue Jan 16, 2013 · 34 comments
Closed

Cut support for IE6-8 and other older browsers. #943

jdalton opened this issue Jan 16, 2013 · 34 comments

Comments

@jdalton
Copy link
Contributor

jdalton commented Jan 16, 2013

With jQuery and Dojo moving away from supporting older browsers (FF3, IE6-IE8, older Opera) I think Underscore is in a good position to drop support as well.

Devs needing older browser support can always use a compat build of Underscore or Lo-Dash (no troll), which has extensive older browser support and a build system to allow selectively supporting older/newer environments.

@lukesutton
Copy link

There are only a small set of projects where you can say support for IE6–8 isn't needed. Unless _ was going to adopt a release cycle like jQuery — parallel, API compatible versions with different support sets — it's too early to start talking about removing support. Alas.

@jdalton
Copy link
Contributor Author

jdalton commented Jan 17, 2013

Unless _ was going to adopt a release cycle like jQuery — parallel, API compatible versions with different support sets — it's too early to start talking about removing support. Alas.

Underscore is billed as "the tie to go along with jQuery's tux" and if the tux, jQuery, drops support, it only makes sense that the tie, Underscore, should follow.

With older browser support and Underscore compatibility handled by something like Lo-Dash, Underscore is free to make the shift, simplifying its code, slimming down, and optimizing for modern browsers/environments, without worrying about back compat.

@knowtheory
Copy link
Collaborator

I took a moment to crunch the access logs DocumentCloud has on hand, and of the 1.8 mil hits in the logs, the IE breakdown looks like this:

      9 MSIE 4.0
     78 MSIE 5.0
     54 MSIE 5.5
   2086 MSIE 6.0
      1 MSIE 6.1
  32700 MSIE 7.0
  67311 MSIE 8.0
  80300 MSIE 9.0
   4199 MSIE 10.0
     19 MSIE 999.1

So, we're still getting 10% of traffic from IE, 5% of total traffic from IE7-8. We're getting close, but i don't feel like we're at the point yet where underscore can go >=IE9

Touched base with some of our users, and they're running between a quarter to 40% traffic from IE, half of those numbers being earlier IE9.

Dropping IE7/8 support isn't a bad idea, i'm just not convinced we should do it yet.

@jdalton
Copy link
Contributor Author

jdalton commented Jan 17, 2013

@knowtheory Thanks for taking the time to crunch numbers! As mentioned compat support is already being provided by other projects so Underscore is free to drop its support for legacy browsers, in future versions, without having to worry about carrying the compat burden.

@lukeasrodgers
Copy link
Contributor

The more I think about this, the more sense it makes, I think. Without wanting to appear overly pedantic when it comes to versioning, I would expect dropping support for legacy browsers to necessitate a version bump to 2.0.

You might make your case stronger by listing some examples of the inconsistent support for legacy browsers. I'm aware of the handling of sparse arrays but not any others off the top of my head.

@jdalton
Copy link
Contributor Author

jdalton commented Jan 17, 2013

You might make your case stronger by listing some examples of the inconsistent support for legacy browsers. I'm aware of the handling of sparse arrays but not any others off the top of my head.

Besides sparse array inconsistencies, there are object/function/string iteration inconsistencies as well.

In IE < 9 Underscore will not iterate arguments objects as objects correctly (so in methods like _.keys and _.isEmpty) because it won't iterate over their index values, Underscore won't iterate strings as array-like values, and will skip iterating own constructor, hasOwnProperty, isPrototypeOf, propertyIsEnumerable, toLocaleString, toString, and valueOf properties of objects.

Also, Underscore will incorrectly iterate the usually non-enumerable prototype property of functions in older versions of Firefox, Opera, and Safari.

Underscore is the only mainstream lib, with older browser support, that doesn't attempt to solve any of these compatibility/consistency issues. With an alternative that does handle these older browser issues, now is a great time for Underscore to cut support.

@rwaldron
Copy link

+1

I'm not dog-piling, I'm advocating.

@sindresorhus
Copy link
Contributor

👍 It's time.

@danheberden
Copy link

+1

If you'd like to stay similar to jQuery, users can always use an older version of underscore if support for IE6-8 is necessary.

@phated
Copy link

phated commented Jan 17, 2013

The point to use a library for some of these things is consistency with old browsers, and if underscore isn't achieving that, then let lo-dash handle it and cut the support.

@mathiasbynens
Copy link

+9001 — Let’s move the web forward. Any project even half as popular as Underscore can make a difference.

A note with a link to an older version of Underscore (or an oldIE-compatible build of Lo-Dash) could be added to the README for those who still need to support older browsers (gah — for some projects I still need to!).

@monteslu
Copy link

+9002 We'll always have people using IE8 if we keep supporting it.

@anthonyshort
Copy link

👍

@caseywebdev
Copy link
Contributor

👍 to injecting code that will permanently erase IE from a user's machine

@zzolo
Copy link

zzolo commented Jan 17, 2013

We love underscore and use it on many projects. Thanks for all the great work.

We still have 20%+ of our users on IE8, while IE7 sees less than 4%. We have basically decided to fully support IE8 and loosely support IE7.

I would agree with dropping support for IE7 and definitely IE6. I would also possibly agree with dropping active support for IE8 if the gaps could be filled in with something like es5shim.

A few specific questions to ask about whether to keep support:

  • What are the specific missing parts of IE6/7/8?
  • What is the amount of work needed to support these browsers?
  • Will someone maintain support for old browsers?
  • What is the browser breakdown for the users of this library? (assuming everyone, so general stats would be good)

@jdalton
Copy link
Contributor Author

jdalton commented Jan 17, 2013

A few specific questions to ask about whether to keep support:

What are the specific missing parts of IE6/7/8?

I covered the missing parts in the comment above.
Dropping IE 6/7/8 and other old browsers would allow Underscore to remove its fallbacks and fixes for older browsers.

Will someone maintain support for old browsers?

Underscore could provide a separate build or defer to Lo-Dash which will maintain support for Underscore and older browsers through its build feature and ship with pre-built versions, maintained in cdnjs as well.

@knowtheory
Copy link
Collaborator

@jdalton btw, are there failing test cases somewhere for the inconsistencies you've mentioned?

Running the test suite in IE7 only turns up a single failure at the moment.

@danheberden
Copy link

@lukesutton

If you're using an older browser that doesn't get updates and new APIs itself, why would you be concerned with getting new APIs and features from Underscore? It seems reasonable that if you are developing for IE7, for example, that using jQuery 1.9 and an older version of Underscore (or current version of lodash) is completely reasonable.

I would love to see more libraries take the dual path approach similar to jQuery. Keep the old version around, and possibly update it if there is a significant bug or something. Otherwise, new development and features are solely for modern browsers. Otherwise, we'll never cut the cord.

@jdalton
Copy link
Contributor Author

jdalton commented Jan 18, 2013

@knowtheory

are there failing test cases somewhere for the inconsistencies you've mentioned?
Running the test suite in IE7 only turns up a single failure at the moment.

Yikes on the failing IE7 test case. The issues are covered in the Lo-Dash test suite, but Underscore is not compatible with it ATM due to testing lib specific API. The consistency/campat issues I've mentioned above are issues Underscore explicitly has punted on (showing no interest in resolving).

@sindresorhus
Copy link
Contributor

what @danheberden said.

@lukesutton
Copy link

@danheberden You make a good point. Underscore could essentially ask people needing backwards compatibility to just stick with an older version of the API. However, I strongly disagree with that. Why should anyone needing backwards compatibility miss out?

I feel it's important to discuss and plan for deprecations, but in this case it is premature and feels hostile to users.

@danheberden
Copy link

@lukesutton I see what you mean - and a year ago, I would have been on your side of this. But to

Why should anyone needing backwards compatibility miss out?

They already are if they're using IE6-8. On a lot.

@jdalton
Copy link
Contributor Author

jdalton commented Jan 24, 2013

I'm cleaning the issue up (removing the OT parts) and re-opening for further discussion.

A reminder the gist of this issue is that with older browser support removed, Underscore is free to make the shift, simplifying its code, slimming down, and optimizing for modern browsers/environments.

Of course there will be some compat strategy (like a separate build or older version).
For one possible compat strategy see this jQuery blog post.

@jdalton jdalton reopened this Jan 24, 2013
@knowtheory
Copy link
Collaborator

@jdalton, you deleted Jeremy's response to your claim that underscore has backwards compatibility issues.

His response seems pretty core to the topic, so it's frustrating that you've done so.

In lieu of more specific documentation of the particular issues you are concerned with supporting in IE7/8, it's hard to assess what trade-offs you're asking to make. And again, it's frustrating that you just removed part of the conversation that pertains to whether IE support is problem to support or not (Jeremy's claim being that it's not).

@jashkenas
Copy link
Owner

Reopening for discussion is alright ... but in the future, do not delete other peoples' comments on GitHub issues, or go back and edit them. You haven't been doing that in any other ticket, have you?

To repeat myself: Underscore should always be a simple, single script that supports all of the environments you're likely to encounter as a JavaScript developer out of the box. Code that is written to work against one version of Underscore should just work, cross-platform.

I'd suggest forking, and creating a version that doesn't support Internet Explorer ... but you've already gone there ;)

@jdalton
Copy link
Contributor Author

jdalton commented Jan 24, 2013

@jashkenas Thanks for reiterating your point, and sorry @knowtheory for the stepping on toes, just wanted a clean, non-OT derailed, discussion : )

@thejefflarson
Copy link

this is on topic? (#943 (comment)) But my complaint that I (and I bet loads of others) need support for the IEs, and that having one script that is supported isn't? Something smells fishy here.

@michaelficarra
Copy link
Collaborator

@jdalton: I don't think you understand quite how wrong it was to do what you did. You might feel that it was no big deal and that you were just tidying up the conversation (a noble goal), but those affected by your actions likely feel that their speech was stifled. That feeling can really suck. I think they at least deserve an apology and a promise not to do it again, don't you?

@jdalton
Copy link
Contributor Author

jdalton commented Jan 24, 2013

@michaelficarra I see where you're coming from and have been frustrated by the removal of on topic comments in the past. I made a judgement call, and in this case the thread, which was supposed to be about dropping older browser support, became de-railed with third party lib questions (partially my fault), personal attacks, and other tangents that only distracted from the discussion and made it harder to follow. I announced the thread reset to allow devs who have commented or are following the issue, to re-approach the issue and have further discussion (even if that means reiterating a previously made point).

@jdalton
Copy link
Contributor Author

jdalton commented Jan 31, 2013

For those interested, there's a nice discussion over an old-browser-compat breaking change introduced in Underscore v1.4.4 over at underscore/commit/ce3d1a

@davidmoshal
Copy link

Removing IE6-8 support would make underscore incompatible with the majority of large corporations, where IE 7-8 have significant usage.

http://blog.lytzen.name/2013/05/real-world-corporate-browser-stats.html

@michaelficarra
Copy link
Collaborator

@davidmoshal: While at the same time, Google Apps just dropped support for IE9 and below. These examples don't help much.

@davidmoshal
Copy link

@michaelficarra: doesn't help us, we still have to support enterprise clients, the vast majority of whom are on IE8, some on IE7. The reason for the old browser versions has to do with an (entirely reasonable) desire to update all of their machines, in sync, periodically every 3-5 years. Sadly, I don't see your average Fortune 100 company running out and ordering 50,000 new laptops based on Google's action alone. It would be cheaper and less disruptive to find alternative functionality. Remind me, does underscore have 'legacy' versions like lodash and others do?

@spadgos
Copy link
Contributor

spadgos commented Nov 19, 2013

does underscore have 'legacy' versions like lodash and others do?

@davidmoshal it has versions 0 -> current which all support IE6-8. Though they're out of date, they still exist and can be used. I think those in favour of dropping IE6-8 support are suggesting that developers who need to support these browsers use (what would soon become) an older version of underscore, or something like lodash in compatibility mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests