-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
dropping IE8 support #3828
Comments
Yep, this seems like a good idea to me. As dependencies drop support Backbone will implicitly lose support anyway. Syncing those up seems like a good plan. |
+1 |
I'm down with this but what specifically do we need to fix? We can finally use |
Besides being able to adopt various ES5 methods I scanned Backbone I see fixes for |
Again, those are all iframe issues. How do they affect us from moving forward on things?
We got rid of those from Underscore, remember? It's mostly just Object.create as I can see. |
Dropping support means less code, less workarounds, less testing overhead, generally less headaches, and allows expanding features to the new lowest common denominator instead of boxing features to what's doable in IE6 or IE8.
|
Can you give me an example of where that's happening currently? It seems we're mostly talking about minor code changes, not anything fundamentally different with Backbone. The iframe section could be removed, but it's not a ton of code. |
I'm not really involved in the day-to-day of Backbone, maybe @jridgewell or @braddunbar have more insights into that. I know in developing Lodash that the issue of scoping features to the lowest supported environment comes up plenty for things like Map/Set/WeakMap, null prototypes, etc.
The reduction in code and complexity is nice though I can see how something like support/triage may be a bigger win for you. I know debugging older IE issues isn't the easiest and many devs lack the vms for it. You may be volunteering to be the old-IE-support-contact which is cool I guess. |
Don't discount all the History fixes we've done (more than just the iFrame). I've tried refactoring router code a few times, and I'm always frustrated with all of the legacy code there.
Thankfully, jQuery took the brunt of the IE code fixes. History is the only code I know of where we've had to work around it. |
As jQuery moves away from IE8 support will Backbone take on the support burden for those fixes? |
Nah, that's all end-dev code in the Views and Ajax requests. It's up to them to backfill anything they're missing by updating to the latest jQuery. |
So to clarify Backbone won't drop IE8 support even though jQuery & Microsoft are, but also won't put in the effort to extend support beyond History. Is that correct? 😧 |
If we can get rid of the IE workarounds in History, I'm 👍. |
👍 I'm not certain what extra features we'll gain by dropping IE8 support but I am certain we won't gain anything by keeping it past it's end of support. |
Re: #3778 We could define a getter/setter to stop this: Model.prototype = {
// ...
get id() {
return this.get(this.idAttribute);
}
set id(id) {
this.set(this.idAttribute, id);
}
} |
So is there news about jQuery somewhere? I know 2.x doesn't support IE8.. neither does 3.x, but are they stopping development of their 3.x-compat branch? |
@paulfalgout Yes the plan is to not have a 3.x-compat branch. There is no official post yet. |
Here we were using a lot of IE8 fallbacks stuff, now (at Airbus company) they are moving to IE11 before 2016. |
👍 |
On Jan 12, 2016 MS is essentially dropping support for IE8. With that in mind jQuery and Lodash are dropping IE8 support in their 3.0 and 4.0 releases. So let's discuss dropping it in the next major bump of Backbone.
The text was updated successfully, but these errors were encountered: