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 discussion on the RFC proposal, 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 upgrade to Ember 2.0. And because of the
Semantic Versioning guarantees in the Ember 2.x series, you may only have
few issues when upgrading 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.
Ecosystem
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
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, 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.