Ember may drop support for IE8 and IE9 in 2.0

In the spirit of a previous topic discussing IE6 and IE7, I noticed there was a request for comments about dropping IE8 support in Ember.js:


IE9 may be dropped based on low stats, too:

The public trackers have IE9 at a lower share of total usage than IE8, so it might be worth considering dropping them together. Our decision for Ember 2.0 will likely hold until late 2016, so it’s worth considering more than just the current moment when making the decision.

Personally I think this is great. Drop both IE8 and IE9 support for everyone’s sanity. :+1:

We never supported IE8 in Discourse, and we barely support IE9 because lack of pushState makes it pretty painful to actually use. We’re probably going to drop IE9 support altogether by the end of 2015.

In contrast, we’ve never had issues with IE10 or IE11 and I personally use IE11 on a regular basis on my Surface 3 Pro.

This is a very detailed, thoughtful proposal from @wycats – what do you think?


Definitely like it; I’m a Windows dev also (and IE 11 user). I am concerned it might alienate a small number of folks that are supporting a legacy corporate infrastructure (not sure how many people would be affected by that)… but the positive would outweigh the negative

IMO, it would be best to drop it now to prevent another “OMG doesn’t work in IE6 (…in 201x)” scenario w/ IE 8; just cut the cord now


I certainly see the appeal of dropping IE 9 and maybe that’s the best thing for Ember. But at Batterii, we have a few big enterprise customers who don’t provide their employees with a choice of browsers. They’re either in heavy compliance industries (pharma, insurance, etc), or they have overzealous IT. It would be a tough battle for us to drop IE 9 presently.

There were several people in the RFC who made comments alluding to “if you drop IE 9 support, your users will upgrade or use chrome”. And the fact of the matter is that’s not always the case. Every shop has a different set of challenges around this.

Additionally, there may be shops which have signed SLAs that require them to support IE 8/9 for a period of time. This isn’t common, but it’s not unheard of either.

IMHO, no developer really wants to support IE 9, but we all have real world business needs. I think it’s important to keep this in mind.


Personally I would stick to Ember 1.x if this happens. IE8 is a huge PITA to deal with, but dropping support is not something that I would be able to sell, with usage still being around 8%.

I think it’s amusing that it may be possible to support IE8 via FastBoot.


Same problem here, I’d drop support to IE8 and IE9 if i had a chance but I can’t!

@ef4 The idea of making ember apps compatible through fastboot sounds amazing though!

Since the attitude from some of Microsoft’s team seems to be “help us get people off of this thing,” I think we should shift Microsoft browser support to a “last 2 versions” commitment like most folks do with the evergreen browsers. If certain industries are going to insist on using a bad browser in an unsupported OS, I don’t think it’s unreasonable to ask them to also to use unsupported versions of other software, and pay the king’s ransom for engineers with the knowledge/interest to implement solutions on this platform.

Although, to be fair, writing an application for IE8 is certainly “ambitious.”

1 Like

Developers new to the framework tell us that having to remember to use .get() is a big source of confusion. More seasoned developers get used to it

I actually disagree with this. I have been using Ember for a quite a while now and get is just a massive pain to me on a daily basis. Besides the fact it is forcing a slower code path for cases where CPs are not involved it is a lot more to type and frankly, it makes a lot of the code ugly.

I would be delighted to be rid of this, for me this is my #1 pain point with the Ember object model.

Dropping IE8 to me seems like a no-brainer. We don’t need this dead weight in the framework, it is clearly holding up progress. If people insist they need IE8 they can always start maintaining a fork of old Ember without forcing us all to have a inferior development experience.

In the past year I have heard very no complaints that Discourse does not run on IE8 and I monitor everything on meta.

###Regarding IE9.

I do not think people properly appreciate how stunted Ember becomes without the History APIs. People expect reload to work. Hashbang URL are just ugly and bad for SEO. History API is the only real viable option.

I feel quite strongly that Ember should provide a great default routing experience that works in all the platforms it supports. IE9 leaves a real bad taste here.

My vote @wycats and @tomdale is to burn IE8 and IE9 with fire, it is better for Ember, it is better for the Ember community, it opens the door for a pile of perf optimisations that are impossible prior to this move and gives Ember a far more appealing baseline.

There is a timeline which you must consider. Clearly in 10 years you would be fine to drop IE8 support, what about 4 years? What about 2 years? 1 year?

2.0 is going to dictate the support level for ember for the next 3 or so years, easily. We need to keep that in mind when making these decisions.

Another concern is that it is very practical for old consumers of Ember to stick to 1.X while IE8 dies its slow and painful death.


The big question that you need to predict here is when will that day come? Looking at numbers and trends should be feasible at this point in time.

Strong support in favor of dropping IE8/IE9 support. Ember 2.0 and the ecosystem will be much better off.

At Intel, we have already dropped support for IE8 and IE9 in favor of a “last two versions” approach in OpenSAA, like most have done already. Google Apps dropped support for IE9 in October 2013 when IE11 was released.

Microsoft itself is ceasing support of old versions of Internet Explorer in January, when they will only support “the most current version of Internet Explorer available for a supported operating system.” In the Internet Explorer Support Lifecycle Policy FAQ, Microsoft states that “customers have until January 12, 2016, to upgrade their browser after which time the previous versions of Internet Explorer will reach end of support.”

I second the opinion that it seems reasonable for the small minority that truly needs to support old IE to just stay on 1.x until they can drop support. It would seem like they could just hold off on upgrading to 2.0 for a little while until January (7 months from June 12 to January 12) when Microsoft itself has provided an upgrade deadline to users.


I would like to see IE 8 and IE 9 support gone. I don’t think dropping just IE 8 would be good, since IE 9 needs a lot of shims, shams and polyfills too…

I keep reading that .get() could not be necessary any longer. Does that means we could just have var age = model.age instead of var age = this.get('model.age')? If so, how would that work? What about .set()?

My vote would be to drop support so core team can focus and allow interested users to maintain support via an addon. Disproportionate resource demands for ancient, non-compliant, and feature-poor browsers can only slow progress and harm performance for the better-behaved ones.

1 Like

Read about es5 properties, this has been available since 2007 John Resig - JavaScript Getters and Setters

It would require some other internal changes to cut off the need for proxies but is definitely doable.

The timing of this is a bit awkward. The reality is that many enterprise users are still using IE9. Up until now emberjs has been a boon with those clients because of it’s great support for older browsers. This means that there are many organisations that are heavily invested in ember apps that are now going to be left in a difficult situation.

There’s a couple of potential solutions being mentioned, fast boot and remaining on the ember 1 series. Fast boot seems like a non-starter as unless your app doesn’t use actions your app still needs to be able to run once the first render has been delivered to the broswer. Staying on ember 1 is also going to be easier said than done. Part of the reality of working with ember at the moment is that it is a fast moving eco-system and you’re expected to keep up with all of the changes. Hitting the pause button on ember, ember-cli and the various addons that your average app uses is going to be quite a challenge.

I can fully understand the core team not wanting to expend resources on supporting IE9. I do feel however that there should at least be an opportunity for those of us that do need IE9 support to step up and shoulder the burden. As far as I’m aware we’re only talking about the cost of bug fixes and shim support, supporting IE9 wouldn’t mean limiting development of ember in any way.

To my knowledge, this has not been said. There is no secret that I hate IE8 and IE9, but I personally will support whatever platform versions we decide on as a community. Quoting from the RFC intro summary:

Because of this, the core team’s impression is that the costs of IE8 support now far exceed the benefits, and we are considering dropping support for IE8 in Ember 2.0. Before we make the decision, we want to hear from the rest of the community. Supporting IE8 incurs significant cost, both in terms of features and maintenance, and we want the community to help us think through the cost-benefit analysis.

The entire point of the RFC is to get just the kind of feedback that folks are chiming in with, I think the process is working wonderfully!

In my opinion this is not an option, we either all accept that we need to support IE9 or not. Saying “we might support IE9 if you do this special song and dance” is not the “Ember Way”.

For example, one of the largest deficiencies in IE9 is its DOM. If Ember itself did not support IE9 many hacks/workarounds etc would not be needed in the templating layer so future features/changes would not need to account for these quirks. It would be pretty hard to change the way the internals of HTMLBars work from an addon.

Depending on my mood I check analytics somewhere between weekly and daily to see if we’re close to dropping IE9. I can (really!) sympathize with the desire to quit dealing with it, but continued support for IE9 was one of the big requirements for us to be able to move to Ember.

Can we get some more detailed information on the challenges Ember faces in supporting IE9? My complaints with it are largely centered around deficiencies in styling, so I’m not as in touch with the issues Ember has to deal with.

I’d also like to know how these deprecations will work with the plans for handling of the 2.0 release. Will the last Ember 1.X release support IE8/IE9 and 2.0 be basically feature equivalent but remove any shims that handle that support?

Is a timeline available for the 2.0 release? I looked, but couldn’t find one. With sufficient preparation time and more information about the technical issues I might be able to argue for dropping IE9 support, but I’m not going to be able to make a solid case for it solely out of my own issues with IE9.

All that said, we’re fully off IE8 and even extended support for that browser has ended. In my opinion supporting IE8 in a website that accepts credit card transactions is encouraging users towards insecure handling of their payment information. I have no problems whatsoever with dropping IE8 support.

I didn’t mean to suggest that the core team had said that, they have my sympathies and huge gratitude for the work they’ve done supporting IE8/9 to date and I don’t think anyone could begrudge them if they wanted to focus more energy on new features/improvements.

I agree, the RFC has been very successful in gathering a broad range of views from the ember community.

The scenario I was imagining with regards to the community picking up the IE9 support costs was that tickets and fixes would still be in the core repo, simply that there would be no expectation for the core team to pick them up. As you suggest though, perhaps a middle road here isn’t really workable.

1 Like

My opinion is that you go ahead and drop them. Lots of benefits to doing so. Affected devs/companys could stay on the 1.X branch.

If there is more push back, you could consider making the last release of 1.x an LTS release with a commitment to support bug fixes for another additional X months. It may not be necessary, but that would be so much more preferable than keeping IE8 and 9 support in Ember 2.0 IMO.


Looks like a decision was made via @tomdale at: https://github.com/emberjs/rfcs/pull/45#issuecomment-93009469

Hey folks,

This has been an amazing discussion. Big thanks to everyone for contributing your perspectives.

After reviewing this thread, it seems clear that the vast majority of Ember users who have responded, including people working at large corporations, are comfortable with dropping IE8 support in Ember 2.0. On the other hand, while there is enormous support for dropping IE9 support as well, a number of people still rely on support for IE9, and the benefits of dropping IE9 in Ember 2.0 are not as strong.

After reviewing this thread, many in-person conversations with Ember users in large companies, and reviewing the private data sent to us via email, we have decided that Ember 2.0 will support IE9+.

So how are we going to manage this transition, and what should you do if your business still requires IE8 support for the time being?

1.13 with Extended Browser Support

The core team will continue to periodically release point releases in the 1.13 series to patch security bugs and browser compatibility issues, including issues in IE8.

No new features will be added, and we should be clear that we do not intend people to stay on this release unless they must support IE8. Our Semantic Version guarantees mean that the vast majority of the community should migrate to the 2.x series as soon as possible.

It is important to note that Ember 1.13 will come with deprecation warnings for everything that we will break in Ember 2.0. As a result, if you are running Ember 1.13 without any deprecation warnings, you should be able to easily upgrade to Ember 2.0. And because of the Semantic Versioning guarantees in the Ember 2.x series, it should be relatively simple to upgrade from Ember 1.13 to the most recent version of Ember 2.x when you are able to drop IE8 support.

For example, imagine you build the Ember app for Big Widget Enterprise Co. that requires IE8 support. You upgrade to 1.13 (the last release in the 1.x series) and, over time, refactor code to eliminate all deprecation warnings. Periodically, you apply 1.13 patch releases to maintain browser compatibility and to fix potential security issues.

Then, in April of 2016, management decides that enough customers have moved off IE8 that you no longer need to support it. At that time, Ember 2.6 will be the most recent stable release. Because 1.13 without deprecation warnings is forwards-compatible with Ember 2.6, you can upgrade from 1.13 to 2.6 with little hassle.

With the integration of Ember CLI and Ember Data into the Semantic Versioning guarantees, many of your dependencies will follow a similar upgrade path.


Of course, the above guarantees only apply to Ember, Ember Data, Ember CLI, and the rest of the core-supported packages. Addon authors are free to define their own support matrices. We encourage those who depend on older browsers to contribute back by submitting PRs to the addons they use with compatibility patches. Likewise, we encourage authors of existing addons to work with users to offer a browser compatibility matrix as close to the core projects as possible.

If you require support for IE8 (and as a result, Ember 1.13), make sure to make your voice heard across the addon ecosystem.

That said, you should expect that new addons that come out after Ember 2.0 will not target Ember 1.13, and you should factor that into your decision to remain on the 1.13 Extended Browser Support release of Ember.


FastBoot, our effort to bring server-side rendering to all Ember apps, is designed to offer even users with slow, low-feature browsers a fast experience. While most people think of this as a benefit to mobile users, IE8 certainly qualifies as a slow, low-feature browser.

Because Ember applications are written “route first”, any idiomatic Ember content app that uses links as the primary mode of navigation will be able to provide a passable experience for users with an unsupported version of JavaScript, or no JavaScript at all.

It is worth noting that FastBoot, in the medium term, will have good support for read-only content sites. However, while it is possible to support forms pretty easily, forms without JavaScript (using cookie authentication) introduce the prospect of CSRF attacks. A good solution for FastBoot forms that is also secure is probably a longer-term project. We would encourage the community to experiment with a secure approach to forms that works with FastBoot.

jQuery Compatibility

In our RFC, we mentioned that dropping IE8 will give us the opportunity to remove jQuery as a strict dependency. We should have been clearer that we have no intent to remove the Ember APIs that delegate to jQuery (such a Ember.$ and this.$() inside components).

Because these APIs will remain in 2.0, both for ease of upgrade and because we have not yet made the jQuery dependency optional, Semantic Versioning prohibits us from removing them until at least Ember 3.0.

On a personal note, we rely on jQuery heavily in our own apps. We think it’s a great library that remains hugely valuable to smooth over clunky DOM APIs and browser quirks (even in modern browsers). For those users who need the absolute smallest payload size, we don’t want to saddle you with a dependency that you don’t need. But we expect the majority of users to continue using jQuery, and we have no plans to remove the Ember/jQuery integration at this time.

Thank you again for everyone who took the time to help us make this decision, and thank you so much for being a part of the Ember community.

@tomdale @wycats a bit unclear on

  1. Does anything happen on Jan 2016 when MS drop support for IE9?
  2. How long is Ember committing to support IE9 for?

via twitter