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

Solicit feedback about IE8 and IE9 support in Ember 2.x #45

Merged
merged 2 commits into from Jun 7, 2015

Conversation

Projects
None yet
@wycats
Member

wycats commented Apr 4, 2015

RFC

@lukemelia

This comment has been minimized.

Show comment
Hide comment
@lukemelia

lukemelia Apr 4, 2015

Member

In Yapp's own products, we have not supported IE8 for a few years. In Yapp Labs' Ember consulting projects, I would estimate that 5-10% of our clients require IE8 support for their applications. After reading this RFC, I am in favor of dropping IE8 support for Ember 2.x. I'm less sure about IE9.

Member

lukemelia commented Apr 4, 2015

In Yapp's own products, we have not supported IE8 for a few years. In Yapp Labs' Ember consulting projects, I would estimate that 5-10% of our clients require IE8 support for their applications. After reading this RFC, I am in favor of dropping IE8 support for Ember 2.x. I'm less sure about IE9.

@cport1

This comment has been minimized.

Show comment
Hide comment

cport1 commented Apr 4, 2015

IE10+

@SebastianEdwards

This comment has been minimized.

Show comment
Hide comment
@SebastianEdwards

SebastianEdwards Apr 4, 2015

👍 we've already dropped support for anything less than < IE10.

👍 we've already dropped support for anything less than < IE10.

@ryanflorence

This comment has been minimized.

Show comment
Hide comment

Microsoft is dropping support January 2016. Is 8 months worth it?

https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=internet%20explorer

@chrisbateman

This comment has been minimized.

Show comment
Hide comment
@chrisbateman

chrisbateman Apr 4, 2015

@ryanflorence beat me to it. Additionally - IE9 will only be supported on Vista, which has pretty small market share.
Oh - and if you're going to drop 9, you might as well drop 10 too.
Alternate link: http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx

@ryanflorence beat me to it. Additionally - IE9 will only be supported on Vista, which has pretty small market share.
Oh - and if you're going to drop 9, you might as well drop 10 too.
Alternate link: http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx

@workmanw

This comment has been minimized.

Show comment
Hide comment
@workmanw

workmanw Apr 4, 2015

Contributor

At Batterii we haven't supported IE 8 for years. All of our customers are enterprise and we find roughly about 15% of our users are on IE 9. Loss of IE 9 support would be tough for us because it could mean the loss of a few big customers.

Whatever you decide, the more advanced notice, the better.

Contributor

workmanw commented Apr 4, 2015

At Batterii we haven't supported IE 8 for years. All of our customers are enterprise and we find roughly about 15% of our users are on IE 9. Loss of IE 9 support would be tough for us because it could mean the loss of a few big customers.

Whatever you decide, the more advanced notice, the better.

@stclair

This comment has been minimized.

Show comment
Hide comment
@stclair

stclair Apr 4, 2015

IE 10+. Our experience dropping support for IE8 and limiting support for IE9 has been overwhelmingly positive. Customer criticism has been almost nonexistent.

stclair commented Apr 4, 2015

IE 10+. Our experience dropping support for IE8 and limiting support for IE9 has been overwhelmingly positive. Customer criticism has been almost nonexistent.

@ryanflorence

This comment has been minimized.

Show comment
Hide comment
@ryanflorence

ryanflorence Apr 4, 2015

about 15% of our users are on IE 9

Sometimes I've confused "visits" with "users". Just because you have 15% of visits on IE 9 doesn't mean that 15% of your users will be hosed. Many users will use multiple browsers.

Obviously, everybody's customers are different. I've generally been developing software for university students and teachers, its totally normal for them to use multiple browsers. For others, maybe 15% IE9 visits really does mean 15% of users. Just something to consider when discussing browser support.

about 15% of our users are on IE 9

Sometimes I've confused "visits" with "users". Just because you have 15% of visits on IE 9 doesn't mean that 15% of your users will be hosed. Many users will use multiple browsers.

Obviously, everybody's customers are different. I've generally been developing software for university students and teachers, its totally normal for them to use multiple browsers. For others, maybe 15% IE9 visits really does mean 15% of users. Just something to consider when discussing browser support.

@nchase

This comment has been minimized.

Show comment
Hide comment
@nchase

nchase Apr 4, 2015

dropping IE8 and 9 sounds like a great idea.

nchase commented Apr 4, 2015

dropping IE8 and 9 sounds like a great idea.

@Pradeek

This comment has been minimized.

Show comment
Hide comment
@Pradeek

Pradeek Apr 4, 2015

Assuming this goes through, how long will 1.x with IE8/9 be supported after 2.0 is released? In terms of bug fixes, of course.

Pradeek commented Apr 4, 2015

Assuming this goes through, how long will 1.x with IE8/9 be supported after 2.0 is released? In terms of bug fixes, of course.

@workmanw

This comment has been minimized.

Show comment
Hide comment
@workmanw

workmanw Apr 4, 2015

Contributor

@ryanflorence Nope, these are individual users. Tracked with Intercom.io. Since we only have larger enterprise customers, individual users often don't have a choice of which browser they use. Internal IT locks their computers down. We're starting to see the tides turn on this topic, but a few of our biggest customers are still IE 9 only.

EDIT: I'm not advocating Ember should support IE 9. I know that's not free. Just providing the details of my situation :)

Contributor

workmanw commented Apr 4, 2015

@ryanflorence Nope, these are individual users. Tracked with Intercom.io. Since we only have larger enterprise customers, individual users often don't have a choice of which browser they use. Internal IT locks their computers down. We're starting to see the tides turn on this topic, but a few of our biggest customers are still IE 9 only.

EDIT: I'm not advocating Ember should support IE 9. I know that's not free. Just providing the details of my situation :)

@brandonweiss

This comment has been minimized.

Show comment
Hide comment
@brandonweiss

brandonweiss Apr 4, 2015

Yessss. Kill it with fire.

Yessss. Kill it with fire.

@bradly

This comment has been minimized.

Show comment
Hide comment
@bradly

bradly Apr 4, 2015

IE 8/9 contribute to a significant part of our user's browser usage, but that being said, I think as long as it is clear on not only what you support, but how you plan on depreciating browers in the future all will be well. For instance, Angular dropped IE 8 support when moving from 1.2 to 1.3 which was unexpected and now we have multiple teams already using Angular that have to stick to 1.2.x or move to a different. Not a great place to be in.

bradly commented Apr 4, 2015

IE 8/9 contribute to a significant part of our user's browser usage, but that being said, I think as long as it is clear on not only what you support, but how you plan on depreciating browers in the future all will be well. For instance, Angular dropped IE 8 support when moving from 1.2 to 1.3 which was unexpected and now we have multiple teams already using Angular that have to stick to 1.2.x or move to a different. Not a great place to be in.

@ryanlower

This comment has been minimized.

Show comment
Hide comment
@ryanlower

ryanlower Apr 4, 2015

👍 for dropping

👍 for dropping

@opsb

This comment has been minimized.

Show comment
Hide comment
@opsb

opsb Apr 4, 2015

The majority of our users are unfortunately using IE9 (corporate clients). Very happy to see support for IE8 dropped though.

opsb commented Apr 4, 2015

The majority of our users are unfortunately using IE9 (corporate clients). Very happy to see support for IE8 dropped though.

@RandomEtc

This comment has been minimized.

Show comment
Hide comment
@RandomEtc

RandomEtc Apr 4, 2015

Dropping IE8 seems compelling. Why not start there and drop .get etc?

If there are significant feature gains to be had by dropping IE9 support during 2.x, why not mint Ember 3.0 at that time when those features are the next most compelling thing? Adherence to semantic versioning is honorable, but there are plenty of numbers higher than 2, you won't run out.

Dropping IE8 seems compelling. Why not start there and drop .get etc?

If there are significant feature gains to be had by dropping IE9 support during 2.x, why not mint Ember 3.0 at that time when those features are the next most compelling thing? Adherence to semantic versioning is honorable, but there are plenty of numbers higher than 2, you won't run out.

@aaronbhansen

This comment has been minimized.

Show comment
Hide comment
@aaronbhansen

aaronbhansen Apr 4, 2015

We stopped supporting IE 8 and IE9 in our apps after continuing to run into issues. I support dropping both.

We stopped supporting IE 8 and IE9 in our apps after continuing to run into issues. I support dropping both.

@ryanbillingsley

This comment has been minimized.

Show comment
Hide comment
@ryanbillingsley

ryanbillingsley Apr 4, 2015

Microsoft in some of their own projects are going to IE10+ for browser matrixes, so at the very least, dropping IE8 is a good idea.

Microsoft in some of their own projects are going to IE10+ for browser matrixes, so at the very least, dropping IE8 is a good idea.

@landongn

This comment has been minimized.

Show comment
Hide comment
@landongn

landongn Apr 4, 2015

IE8, specifically, feels like something that will painfully impact a small subset of the overall community, for an otherwise great gain for the rest of us.

For new projects, in the real world, I would say a lack of IE8 support would be pretty understandable, and pegging those projects at 1.14.x seems like a logical solution, however imperfect it would be.

jQuery dropping support for > 1.9 had a near 12% (1) drop in line count, just from those compatibility fixes. jQuery today (2.1.3) tags in around just under 9400 lines of code, for a reduction of around 1000 lines.

Ember canary (debug) is sitting around 48,000 lines, and if similar results were typical, would see a net reduction in 5,700 lines.

Less code is better code, in my book. It's a big, fat, 👍 from me.

(1) : http://blog.jquery.com/2013/04/18/jquery-2-0-released/

landongn commented Apr 4, 2015

IE8, specifically, feels like something that will painfully impact a small subset of the overall community, for an otherwise great gain for the rest of us.

For new projects, in the real world, I would say a lack of IE8 support would be pretty understandable, and pegging those projects at 1.14.x seems like a logical solution, however imperfect it would be.

jQuery dropping support for > 1.9 had a near 12% (1) drop in line count, just from those compatibility fixes. jQuery today (2.1.3) tags in around just under 9400 lines of code, for a reduction of around 1000 lines.

Ember canary (debug) is sitting around 48,000 lines, and if similar results were typical, would see a net reduction in 5,700 lines.

Less code is better code, in my book. It's a big, fat, 👍 from me.

(1) : http://blog.jquery.com/2013/04/18/jquery-2-0-released/

@evrowe

This comment has been minimized.

Show comment
Hide comment
@evrowe

evrowe Apr 4, 2015

While we have to continue supporting IE8 at HealthSparq for the time being, based on usage statistics, the front end engineering team has been pushing to drop support for 8 (and potentially 9, which has very low usage for us) for some time. Reading through the RFC makes it clear that the costs of supporting IE8 in Ember 2.0 are higher than the benefits said support would provide.

I'm in favor of dropping it, for the good of the framework (and hopefully the ecosystem), and as it might provide us with the ammunition we need to move our internal browser support matrix forward.

👍

evrowe commented Apr 4, 2015

While we have to continue supporting IE8 at HealthSparq for the time being, based on usage statistics, the front end engineering team has been pushing to drop support for 8 (and potentially 9, which has very low usage for us) for some time. Reading through the RFC makes it clear that the costs of supporting IE8 in Ember 2.0 are higher than the benefits said support would provide.

I'm in favor of dropping it, for the good of the framework (and hopefully the ecosystem), and as it might provide us with the ammunition we need to move our internal browser support matrix forward.

👍

@jmurphyau

This comment has been minimized.

Show comment
Hide comment
@jmurphyau

jmurphyau Apr 4, 2015

Our application is an app to help manage the technical side of contact centres - targeted towards enterprises. I just asked a colleague should we/will we support IE8 and sent him the link and he's response was this:

"We can alway package [app] as a thick client application for these people"

Maybe not everyone is in a position of being able to install a thick client app in an organisation that is large and still uses IE8 - but it would be something to help users who can't stop using IE8. There are a whole heap of tools that enable packaging web apps as thick client apps.

+1 to dropping IE8.

Our application is an app to help manage the technical side of contact centres - targeted towards enterprises. I just asked a colleague should we/will we support IE8 and sent him the link and he's response was this:

"We can alway package [app] as a thick client application for these people"

Maybe not everyone is in a position of being able to install a thick client app in an organisation that is large and still uses IE8 - but it would be something to help users who can't stop using IE8. There are a whole heap of tools that enable packaging web apps as thick client apps.

+1 to dropping IE8.

@felixrieseberg

This comment has been minimized.

Show comment
Hide comment
@felixrieseberg

felixrieseberg Apr 4, 2015

As a Microsoft engineer I have to point out that everything above Windows XP can and should upgrade to at least IE9 today. In addition, it's important to consider that still running Windows XP is outright dangerous, as it is no longer supported from our end.

Personally, I'd even appreciate dropped support. It feels silly to keep technology more than a decade old on life support, especially if we already dropped support.

As a Microsoft engineer I have to point out that everything above Windows XP can and should upgrade to at least IE9 today. In addition, it's important to consider that still running Windows XP is outright dangerous, as it is no longer supported from our end.

Personally, I'd even appreciate dropped support. It feels silly to keep technology more than a decade old on life support, especially if we already dropped support.

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Apr 4, 2015

i really appreciate how much you folks care about this. I personally want IE8 gone, but the RFC reflects really well on the Ember community. I'm sure the best decision will be made in the end. Thanks everyone!

jrobeson commented Apr 4, 2015

i really appreciate how much you folks care about this. I personally want IE8 gone, but the RFC reflects really well on the Ember community. I'm sure the best decision will be made in the end. Thanks everyone!

@tylr

This comment has been minimized.

Show comment
Hide comment
@tylr

tylr Apr 4, 2015

I would strongly encourage the ember core team to drop IE8 support.

In January of 2014 IE8 accounted for 0.91% of bustle.com's session traffic. Today, that number is down to 0.11% even though we have continually improved our IE8 support. What kind of organization is making high cost technical decisions to support such a small minority of users familiar with a bad web experience?

Even if you look outside of the ember ecosystem, IE8 support no longer seems practical. Without features like CORS, support imposes impractical methods for modern API and service development. For example, the origin of services should be transparent, not conflated with the workflow of building client applications for the browser, which you do by sharing the same host. You could make similar arguments for every modern browser feature not in IE8, even IE9.

Alternative IE8 support idea
I believe a better experience could be provided by way of ember-cli-fastboot. modern progressive enhancement???

Why not offer static content to older browsers that aren't capable of the modern web UI interaction? If the argument for IE8 is simply political, this is a viable solution. Especially considering that the value proposition for js frameworks is to provide more interactive tailored product experiences.

I believe the burden of continued support of IE8 would outweigh the cost of looking into alternatives for both ember developers and ember product developers.

tl;dr Just saying ember supports IE8 doesn't mean anything. The ecosystem that makes ember great never actually will. Nobody is building great products with modern UIs that support it. It does not seem practical nor conducive to the ember community to make IE8 support a part of the scope of the framework.

tylr commented Apr 4, 2015

I would strongly encourage the ember core team to drop IE8 support.

In January of 2014 IE8 accounted for 0.91% of bustle.com's session traffic. Today, that number is down to 0.11% even though we have continually improved our IE8 support. What kind of organization is making high cost technical decisions to support such a small minority of users familiar with a bad web experience?

Even if you look outside of the ember ecosystem, IE8 support no longer seems practical. Without features like CORS, support imposes impractical methods for modern API and service development. For example, the origin of services should be transparent, not conflated with the workflow of building client applications for the browser, which you do by sharing the same host. You could make similar arguments for every modern browser feature not in IE8, even IE9.

Alternative IE8 support idea
I believe a better experience could be provided by way of ember-cli-fastboot. modern progressive enhancement???

Why not offer static content to older browsers that aren't capable of the modern web UI interaction? If the argument for IE8 is simply political, this is a viable solution. Especially considering that the value proposition for js frameworks is to provide more interactive tailored product experiences.

I believe the burden of continued support of IE8 would outweigh the cost of looking into alternatives for both ember developers and ember product developers.

tl;dr Just saying ember supports IE8 doesn't mean anything. The ecosystem that makes ember great never actually will. Nobody is building great products with modern UIs that support it. It does not seem practical nor conducive to the ember community to make IE8 support a part of the scope of the framework.

@mutewinter

This comment has been minimized.

Show comment
Hide comment
@mutewinter

mutewinter Apr 4, 2015

At Beatport, we only target IE10 and up.

At Beatport, we only target IE10 and up.

@kencheeto

This comment has been minimized.

Show comment
Hide comment
@kencheeto

kencheeto Apr 4, 2015

We don't support IE8 in our Ember app at Zendesk. IE9 is probably on the way out as well.

We don't support IE8 in our Ember app at Zendesk. IE9 is probably on the way out as well.

@nanuxbe

This comment has been minimized.

Show comment
Hide comment
@nanuxbe

nanuxbe Apr 4, 2015

I guess we all want to drop ie8 support. Some of our corporate customers dont't. People have always been reluctant to change and keeping ie8 support is enabling them. So my vote is for dropping ie8-9 support.

nanuxbe commented Apr 4, 2015

I guess we all want to drop ie8 support. Some of our corporate customers dont't. People have always been reluctant to change and keeping ie8 support is enabling them. So my vote is for dropping ie8-9 support.

@ShogunPanda

This comment has been minimized.

Show comment
Hide comment
@ShogunPanda

ShogunPanda Apr 4, 2015

Same here. We don't support anything below 10. Drop this ancient.

Same here. We don't support anything below 10. Drop this ancient.

@bakura10

This comment has been minimized.

Show comment
Hide comment
@bakura10

bakura10 Apr 4, 2015

I do not support IE8 and 9 anymore. Lack of CORS on those browsers is an additional reason why it makes it annoying to use for us. On our end, IE9 usage is also nearly zero.

in all honesty, Ember 1.x is now extremely stable, efficient and has all features I ever need! I can't see why it would be bad for people that require IE8 to simply use the 1.x branch.

As a PHP framework developer we had this same issue of dependency considering how fast new version are released. Most framework dropped support for what were considered "the enterprise version"... and it went smoothly without very few protests.

So +1 for me to drop IE8.

bakura10 commented Apr 4, 2015

I do not support IE8 and 9 anymore. Lack of CORS on those browsers is an additional reason why it makes it annoying to use for us. On our end, IE9 usage is also nearly zero.

in all honesty, Ember 1.x is now extremely stable, efficient and has all features I ever need! I can't see why it would be bad for people that require IE8 to simply use the 1.x branch.

As a PHP framework developer we had this same issue of dependency considering how fast new version are released. Most framework dropped support for what were considered "the enterprise version"... and it went smoothly without very few protests.

So +1 for me to drop IE8.

@cibernox

This comment has been minimized.

Show comment
Hide comment
@cibernox

cibernox Apr 4, 2015

Contributor

I would drop support for both. The current app I'm building still has a 15% of IE9 users(it targets primary and secondary schools) , but we're considering package the app as a desktop NW app for those schools. Surprisingly system administrators are more willing to install new software that to update the browser version due to the amount of security and parental control that schools have. It might also be a solution for other people in this thread

Contributor

cibernox commented Apr 4, 2015

I would drop support for both. The current app I'm building still has a 15% of IE9 users(it targets primary and secondary schools) , but we're considering package the app as a desktop NW app for those schools. Surprisingly system administrators are more willing to install new software that to update the browser version due to the amount of security and parental control that schools have. It might also be a solution for other people in this thread

@topaxi

This comment has been minimized.

Show comment
Hide comment
@topaxi

topaxi Apr 4, 2015

👍 on dropping IE8 and IE9 support. We only support up to the latest two browser versions of each browser.

topaxi commented Apr 4, 2015

👍 on dropping IE8 and IE9 support. We only support up to the latest two browser versions of each browser.

@joeruello

This comment has been minimized.

Show comment
Hide comment
@joeruello

joeruello Apr 4, 2015

Echoing the common voices in this thread, wewe only support 10+. Maybe it may be viable to backport some features to 1.15 for people who are stuck needing to support?

If not, we have found "just install Chrome" to be a simple enough workaround for our clients.

Echoing the common voices in this thread, wewe only support 10+. Maybe it may be viable to backport some features to 1.15 for people who are stuck needing to support?

If not, we have found "just install Chrome" to be a simple enough workaround for our clients.

@karlfreeman

This comment has been minimized.

Show comment
Hide comment
@karlfreeman

karlfreeman Apr 4, 2015

Working within the pharmaceutical sector the browser support matrix we proposed for a large ember application was IE9+. This, the client felt, was a suitable compromise given IE8's current lifespan. So I would be in favour of dropping support for IE8 but not IE9. I suspect IE9 will be the minimum for a while (a much better minimum thats for sure).

Perhaps additional weight could be sought be collating browser support across other frameworks for building applications.

A rising tide lifts all boats.

Working within the pharmaceutical sector the browser support matrix we proposed for a large ember application was IE9+. This, the client felt, was a suitable compromise given IE8's current lifespan. So I would be in favour of dropping support for IE8 but not IE9. I suspect IE9 will be the minimum for a while (a much better minimum thats for sure).

Perhaps additional weight could be sought be collating browser support across other frameworks for building applications.

A rising tide lifts all boats.

@leifcr

This comment has been minimized.

Show comment
Hide comment
@leifcr

leifcr Apr 4, 2015

Since fastboot will prerender on the server, that should be good enough for ie8 and ie9. Any clients stuck on ie8 or ie9 should be aware of the security risk by running a browser that won't get updates...

Dropping at least ie8,and probably ie9 as well.

leifcr commented Apr 4, 2015

Since fastboot will prerender on the server, that should be good enough for ie8 and ie9. Any clients stuck on ie8 or ie9 should be aware of the security risk by running a browser that won't get updates...

Dropping at least ie8,and probably ie9 as well.

@Fed03

This comment has been minimized.

Show comment
Hide comment
@Fed03

Fed03 Apr 4, 2015

+1 drop!

Fed03 commented Apr 4, 2015

+1 drop!

@trek

This comment has been minimized.

Show comment
Hide comment
@trek

trek Apr 4, 2015

Member

I've privately shared a breakdown of Groupon's browsers % by visits, users, and (most importantly) revenue.

For those reading here, IE8's % across the board falls below our browser support threshold. IE9 is still well above this threshold, but sinking. IE8's low use was surprise. We weren't closely monitoring and the last time we re-evaluated support, IE8 use was still strong. This wasn't even that long ago.

We've added a monthly report about browser %s so we can aggressively cut IE9 when it drops below our support threshold.

I strongly encourage anyone who needs IE Classic support to gather and share these numbers publicly or privately to help inform our support decisions.

Member

trek commented Apr 4, 2015

I've privately shared a breakdown of Groupon's browsers % by visits, users, and (most importantly) revenue.

For those reading here, IE8's % across the board falls below our browser support threshold. IE9 is still well above this threshold, but sinking. IE8's low use was surprise. We weren't closely monitoring and the last time we re-evaluated support, IE8 use was still strong. This wasn't even that long ago.

We've added a monthly report about browser %s so we can aggressively cut IE9 when it drops below our support threshold.

I strongly encourage anyone who needs IE Classic support to gather and share these numbers publicly or privately to help inform our support decisions.

@kellyselden

This comment has been minimized.

Show comment
Hide comment
@kellyselden

kellyselden Apr 4, 2015

In my large Ember app, I have to support down to IE9 because that's the lowest version media queries will work. The app is 50% internal and 50% external users, and the internal PCs are locked at IE9. My company is dropping IE9 for IE10 at the end of the year I believe.

In my large Ember app, I have to support down to IE9 because that's the lowest version media queries will work. The app is 50% internal and 50% external users, and the internal PCs are locked at IE9. My company is dropping IE9 for IE10 at the end of the year I believe.

@mixonic

This comment has been minimized.

Show comment
Hide comment
@mixonic

mixonic Apr 4, 2015

Member

Good discussion. I've been thinking about this for a while, and would like to share some additional context.

  • IE8 persists largely because it is the last viable browser on the XP operating system.
  • Microsoft has provided a migration strategy away from IE8 since early 2014 (source, source).
  • In January 2016, Microsoft will officially end the IE8 "extended support" phase (source, source). No additional bug or security fixes.
  • In June, the number of Ember developers who support IE8 is projected to be less than 10% of the community (source), and I believe this percentage is inflated by developers claiming to support IE8 but without any actual IE8 users.
  • Globally, IE8 usage is well below 4% (source). Enterprise numbers certainly differ.

The decision to remove IE8 support does not apply to codebases we work on today, it impacts new codebases that would be started after June. I find it nearly unimaginable that a new project would be started (with Ember especially) requiring IE8 six months before the browser is EOLed.

Ember's six-week release schedule opens to door for IE8 supporters to use a deferred-upgrade strategy. They can continue to use Ember 1.14.x (or start on it) until IE8 support is dropped, then presuming all deprecations have been addressed can move forward to 2.x.

I'm in full support of dropping IE8 support in June. Confirming this now (in April) gives enterprise users plenty of notice.

The question of IE9 is more difficult, but I want to cast it in the light of where web development is moving.

Mobile web development is increasingly important (north america desktop v mobile, global desktop v mobile). My clients demand responsive layouts and mobile-friendly experiences more than they demand legacy IE support. To support great mobile experiences there are a few requirements:

  • Responsive layout
  • Offline capability
  • Leverage multiple CPUs
  • Low latency/bandwidth data transfer
  • Fast, smooth rendering and animation

And IE10 is the browser that added solutions for these challenges:

  • CSS3, Flexbox and Grid Layout
  • IndexedDB, AppCache
  • Web Workers
  • Websockets
  • requestAnimationFrame, Canvas, CSS3

Adding these capabilities to the underlying platform of Ember lets us focus on solutions that work for desktop applications and the mobile web. It places our bet on the future of the web instead of the past.

Member

mixonic commented Apr 4, 2015

Good discussion. I've been thinking about this for a while, and would like to share some additional context.

  • IE8 persists largely because it is the last viable browser on the XP operating system.
  • Microsoft has provided a migration strategy away from IE8 since early 2014 (source, source).
  • In January 2016, Microsoft will officially end the IE8 "extended support" phase (source, source). No additional bug or security fixes.
  • In June, the number of Ember developers who support IE8 is projected to be less than 10% of the community (source), and I believe this percentage is inflated by developers claiming to support IE8 but without any actual IE8 users.
  • Globally, IE8 usage is well below 4% (source). Enterprise numbers certainly differ.

The decision to remove IE8 support does not apply to codebases we work on today, it impacts new codebases that would be started after June. I find it nearly unimaginable that a new project would be started (with Ember especially) requiring IE8 six months before the browser is EOLed.

Ember's six-week release schedule opens to door for IE8 supporters to use a deferred-upgrade strategy. They can continue to use Ember 1.14.x (or start on it) until IE8 support is dropped, then presuming all deprecations have been addressed can move forward to 2.x.

I'm in full support of dropping IE8 support in June. Confirming this now (in April) gives enterprise users plenty of notice.

The question of IE9 is more difficult, but I want to cast it in the light of where web development is moving.

Mobile web development is increasingly important (north america desktop v mobile, global desktop v mobile). My clients demand responsive layouts and mobile-friendly experiences more than they demand legacy IE support. To support great mobile experiences there are a few requirements:

  • Responsive layout
  • Offline capability
  • Leverage multiple CPUs
  • Low latency/bandwidth data transfer
  • Fast, smooth rendering and animation

And IE10 is the browser that added solutions for these challenges:

  • CSS3, Flexbox and Grid Layout
  • IndexedDB, AppCache
  • Web Workers
  • Websockets
  • requestAnimationFrame, Canvas, CSS3

Adding these capabilities to the underlying platform of Ember lets us focus on solutions that work for desktop applications and the mobile web. It places our bet on the future of the web instead of the past.

@e-oz

This comment has been minimized.

Show comment
Hide comment
@e-oz

e-oz Apr 4, 2015

Support of a11y tools can increase number of visitors much more than IE8,9 support :) In any framework. Just saying :)

e-oz commented Apr 4, 2015

Support of a11y tools can increase number of visitors much more than IE8,9 support :) In any framework. Just saying :)

@aethant

This comment has been minimized.

Show comment
Hide comment
@aethant

aethant Apr 4, 2015

Definite thumbs down on IE8. Take ol' yeller behind the barn, finally.

aethant commented Apr 4, 2015

Definite thumbs down on IE8. Take ol' yeller behind the barn, finally.

@laynegt

This comment has been minimized.

Show comment
Hide comment
@laynegt

laynegt Apr 6, 2015

My previous employer's client base was Fortune 100, and we had planned on dropping IE8 support as soon as early this year. IE8 usage last summer was 10+% and tangibly dropping every month. We were also finding that the conversation with corp IT about installing alternate browsers was often pretty painless, so we were confident we could drive usage down farther. Incidentally, our UX team was a big proponent of dropping IE8 since the experience was so poor.

laynegt commented Apr 6, 2015

My previous employer's client base was Fortune 100, and we had planned on dropping IE8 support as soon as early this year. IE8 usage last summer was 10+% and tangibly dropping every month. We were also finding that the conversation with corp IT about installing alternate browsers was often pretty painless, so we were confident we could drive usage down farther. Incidentally, our UX team was a big proponent of dropping IE8 since the experience was so poor.

@2468ben

This comment has been minimized.

Show comment
Hide comment
@2468ben

2468ben Apr 6, 2015

@dehuszar yeah that's the main unanswered question on this RFC and thread for me: how hard would a polyfill just for IE9 be? IE9 support is clearly not unanimous, but if a polyfill isn't a nightmare, then Ember 2.0 can stay fully lean while products stuck supporting IE9 can focus on a good polyfill.

Even if it's a separately maintained IE9 addon that can't keep compatibility after "Ember 2.5" starts taking advantage of more web tech, it would still get those enterprise products to 2.5 instead of 1.x, and won't bother anyone else's code.

Only if it's not a nightmare.

2468ben commented Apr 6, 2015

@dehuszar yeah that's the main unanswered question on this RFC and thread for me: how hard would a polyfill just for IE9 be? IE9 support is clearly not unanimous, but if a polyfill isn't a nightmare, then Ember 2.0 can stay fully lean while products stuck supporting IE9 can focus on a good polyfill.

Even if it's a separately maintained IE9 addon that can't keep compatibility after "Ember 2.5" starts taking advantage of more web tech, it would still get those enterprise products to 2.5 instead of 1.x, and won't bother anyone else's code.

Only if it's not a nightmare.

@mixonic

This comment has been minimized.

Show comment
Hide comment
@mixonic

mixonic Apr 6, 2015

Member

@wycats talks about a polyfill approach specifically in the RFC. I remain hesitant that it provides any real value. Core team members and contributors would still be expected to support IE9, and moving the code to another repo or addon will not necessarily change the amount of actual effort we expend solving tricky bugs.

FWIW, I'm also uncertain of "corporate stepping up" for IE9. We're seen few large companies interested in sponsoring or contributing to IE6, 7, or 8 support and I would not expect much from them with IE9. Ideas for how to incentivize this are welcome, though we should stay on topic.

Member

mixonic commented Apr 6, 2015

@wycats talks about a polyfill approach specifically in the RFC. I remain hesitant that it provides any real value. Core team members and contributors would still be expected to support IE9, and moving the code to another repo or addon will not necessarily change the amount of actual effort we expend solving tricky bugs.

FWIW, I'm also uncertain of "corporate stepping up" for IE9. We're seen few large companies interested in sponsoring or contributing to IE6, 7, or 8 support and I would not expect much from them with IE9. Ideas for how to incentivize this are welcome, though we should stay on topic.

@andekande

This comment has been minimized.

Show comment
Hide comment
@andekande

andekande Apr 6, 2015

Since Win7 SP1 shipped IE9 it still is the browser to go for Users that don't know anything about Windows update or have it disabled for some reason (the MS conspiracy).
My company supports IE9 but we see our clients do allow the operation of Firefox as 2nd Browser on XP, or have upgraded to modern IE on Win7.

Since Win7 SP1 shipped IE9 it still is the browser to go for Users that don't know anything about Windows update or have it disabled for some reason (the MS conspiracy).
My company supports IE9 but we see our clients do allow the operation of Firefox as 2nd Browser on XP, or have upgraded to modern IE on Win7.

@2468ben

This comment has been minimized.

Show comment
Hide comment
@2468ben

2468ben Apr 6, 2015

@mixonic Thanks for the response! The RFC's polyfill section talks only about IE8, not IE9 so I'm glad to hear from someone in the core trenches like you.

I agree that the extra effort (or reliance on a community addon) would be a pain in the ass, I just wondered where it is on like a 1-10 scale, 10 being the pain of IE8 support.

Either way I know that if our enterprise apps had to stay on 1.x, it would still be great, as long as when ember-cli hits 1.0, there's still some way the latest 1.x branch could be supported by it instead of stuck on the alpha track. Even if it's just a one time thing to give all the pre-2.0 apps a final ember-cli snapshot to use.

2468ben commented Apr 6, 2015

@mixonic Thanks for the response! The RFC's polyfill section talks only about IE8, not IE9 so I'm glad to hear from someone in the core trenches like you.

I agree that the extra effort (or reliance on a community addon) would be a pain in the ass, I just wondered where it is on like a 1-10 scale, 10 being the pain of IE8 support.

Either way I know that if our enterprise apps had to stay on 1.x, it would still be great, as long as when ember-cli hits 1.0, there's still some way the latest 1.x branch could be supported by it instead of stuck on the alpha track. Even if it's just a one time thing to give all the pre-2.0 apps a final ember-cli snapshot to use.

@ntodd

This comment has been minimized.

Show comment
Hide comment
@ntodd

ntodd Apr 6, 2015

Considering the benefits, I'd support dropping IE8. Our biggest app has 2.4% of users on IE8, but 26.4% of users on IE9 (most of the rest are Mobile Safari). It's an enterprise app for a medical company and they are very slow to update desktop browsers. Dropping IE9 would be a deal breaker, but IE8 would be fine.

IE9 usage in general may be low, but many corporate environments are still running it.

ntodd commented Apr 6, 2015

Considering the benefits, I'd support dropping IE8. Our biggest app has 2.4% of users on IE8, but 26.4% of users on IE9 (most of the rest are Mobile Safari). It's an enterprise app for a medical company and they are very slow to update desktop browsers. Dropping IE9 would be a deal breaker, but IE8 would be fine.

IE9 usage in general may be low, but many corporate environments are still running it.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Apr 6, 2015

Member

I am fairly opposed to "partial" support or "support by addon". We either support a browser or we don't. If we support it, all changes and releases are tested against it (which is the only way to ensure a platform does not end up completely broken).

Member

rwjblue commented Apr 6, 2015

I am fairly opposed to "partial" support or "support by addon". We either support a browser or we don't. If we support it, all changes and releases are tested against it (which is the only way to ensure a platform does not end up completely broken).

@SamSaffron

This comment has been minimized.

Show comment
Hide comment
@SamSaffron

SamSaffron Apr 6, 2015

"I work with a lot of large enterprises who for some unknown reason still use IE9. I definitely understand not support IE8 since it is not a HTML5 browser, but I don't see why IE9 would need to be dropped now without any real reasons,"

http://discuss.emberjs.com/t/ember-may-drop-support-for-ie8-and-ie9-in-2-0/7721/9

Microsoft itself is ceasing support of old versions of Internet Explorer in January

Seems completely insane to me to keep supporting IE9 for the next 3 years when Microsoft are dropping support in Jan, the 6 month gap can easily be filled by the old corporate dinosaurs running on an old Ember in the interim.

"I work with a lot of large enterprises who for some unknown reason still use IE9. I definitely understand not support IE8 since it is not a HTML5 browser, but I don't see why IE9 would need to be dropped now without any real reasons,"

http://discuss.emberjs.com/t/ember-may-drop-support-for-ie8-and-ie9-in-2-0/7721/9

Microsoft itself is ceasing support of old versions of Internet Explorer in January

Seems completely insane to me to keep supporting IE9 for the next 3 years when Microsoft are dropping support in Jan, the 6 month gap can easily be filled by the old corporate dinosaurs running on an old Ember in the interim.

@weegeekps

This comment has been minimized.

Show comment
Hide comment
@weegeekps

weegeekps Apr 7, 2015

I work on software written for the Legal & Finance sector, a sector which is definitely lagging behind others in terms of decommissioning IE8. A fair sized portion of our customers are still on IE8 due to dependencies on old ActiveX intranet applications that are essential to their business. That said, 👍 for dropping support for IE8. The maintenance cost is too great for continuing to support IE8 long-term and it is unlikely support for IE8 will continue much longer. We've already run into this problem with Angular and that has already started a drive to no longer support IE8.

I do have one request re: the jQuery dependencies. Please try to keep a upgrade path clear for those of us who are using "Ember.$" and "this.$()" in our codebases. I've got codebases littered with "this.$()" and it will significantly increase the difficulty of upgrading to Ember 2.0 if we have to change every instance of those.

I work on software written for the Legal & Finance sector, a sector which is definitely lagging behind others in terms of decommissioning IE8. A fair sized portion of our customers are still on IE8 due to dependencies on old ActiveX intranet applications that are essential to their business. That said, 👍 for dropping support for IE8. The maintenance cost is too great for continuing to support IE8 long-term and it is unlikely support for IE8 will continue much longer. We've already run into this problem with Angular and that has already started a drive to no longer support IE8.

I do have one request re: the jQuery dependencies. Please try to keep a upgrade path clear for those of us who are using "Ember.$" and "this.$()" in our codebases. I've got codebases littered with "this.$()" and it will significantly increase the difficulty of upgrading to Ember 2.0 if we have to change every instance of those.

@nathanhammond

This comment has been minimized.

Show comment
Hide comment
@nathanhammond

nathanhammond Apr 7, 2015

Miscellaneous thoughts:

  • In the 2006-2007 time-frame jQuery would fix crashing bugs and uncaught errors such that it was always safe to include jQuery whether or not that browser was supported by jQuery. If we remove support for older browsers this is an ideal to target because it allows for some fallback code to run which could save us from the "White Screen of Death." A somewhat-graceful failure pattern should be something that we add as we deprecate support for older mainstream browsers (give ourselves a chance to tell users what went wrong).
  • Continuous incremental improvements to FastBoot (such that it might allow for some trivial state manipulation) provides hints at a possible way forward for the next time we have this conversation about Safari, Mobile Safari, AOSP, Xbox Browser, or who knows what else.
  • I agree with @rwjblue that browser support should not come with a "Bring Your Own Compatibility" approach. Without directly accounting for browsers during library feature development we will accidentally break browser compatibility without awareness.
  • The users who will likely have the largest problems with IE8/IE9 are selling into numerous corporations (100+) whose IT departments are well outside of the scope of their relationship. That appears to be a very small minority in the Ember community.
  • Support for IE8 and IE10 ends on January 12, 2016 for user-facing operating systems. Support for IE9 ends on April 11, 2017 for user-facing operating systems. If we elect to maintain support for IE8, IE9, and IE10 those dates should be hard caps as to how long we support them in Ember. (Amusingly, IE9 support is longer than IE10 support.)
  • Completely in favor of dropping IE8 and IE9 when wearing my "personal projects" hat.

Miscellaneous thoughts:

  • In the 2006-2007 time-frame jQuery would fix crashing bugs and uncaught errors such that it was always safe to include jQuery whether or not that browser was supported by jQuery. If we remove support for older browsers this is an ideal to target because it allows for some fallback code to run which could save us from the "White Screen of Death." A somewhat-graceful failure pattern should be something that we add as we deprecate support for older mainstream browsers (give ourselves a chance to tell users what went wrong).
  • Continuous incremental improvements to FastBoot (such that it might allow for some trivial state manipulation) provides hints at a possible way forward for the next time we have this conversation about Safari, Mobile Safari, AOSP, Xbox Browser, or who knows what else.
  • I agree with @rwjblue that browser support should not come with a "Bring Your Own Compatibility" approach. Without directly accounting for browsers during library feature development we will accidentally break browser compatibility without awareness.
  • The users who will likely have the largest problems with IE8/IE9 are selling into numerous corporations (100+) whose IT departments are well outside of the scope of their relationship. That appears to be a very small minority in the Ember community.
  • Support for IE8 and IE10 ends on January 12, 2016 for user-facing operating systems. Support for IE9 ends on April 11, 2017 for user-facing operating systems. If we elect to maintain support for IE8, IE9, and IE10 those dates should be hard caps as to how long we support them in Ember. (Amusingly, IE9 support is longer than IE10 support.)
  • Completely in favor of dropping IE8 and IE9 when wearing my "personal projects" hat.
@mupkoo

This comment has been minimized.

Show comment
Hide comment
@mupkoo

mupkoo Apr 7, 2015

In short, we would be able to implement more features more quickly without the burden of bugs that were first introduced 15 years ago.

This is the part that got me. I would really prefer if Ember's team have more time to focus on new features instead of supporting old software.

mupkoo commented Apr 7, 2015

In short, we would be able to implement more features more quickly without the burden of bugs that were first introduced 15 years ago.

This is the part that got me. I would really prefer if Ember's team have more time to focus on new features instead of supporting old software.

@rtablada

This comment has been minimized.

Show comment
Hide comment
@rtablada

rtablada Apr 7, 2015

@weegeekps I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available, but would not ship as standard and would not be used for core framework code.

rtablada commented Apr 7, 2015

@weegeekps I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available, but would not ship as standard and would not be used for core framework code.

@jherdman

This comment has been minimized.

Show comment
Hide comment
@jherdman

jherdman Apr 8, 2015

I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available

Simply returning the DOM node would be enough, wouldn't it?

jherdman commented Apr 8, 2015

I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available

Simply returning the DOM node would be enough, wouldn't it?

@weegeekps

This comment has been minimized.

Show comment
Hide comment
@weegeekps

weegeekps Apr 8, 2015

I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available, but would not ship as standard and would not be used for core framework code.

@rtablada I would assume so as well, but assumptions are a dangerous thing. Better to call it out now than wish I had later.

Simply returning the DOM node would be enough, wouldn't it?

@jherdman No, this.$() should return a jQuery object for the element. Returning the DOM node directly would end up breaking any code using jQuery functions.

I'd like to know more about the jQuery plan but my assumption would be that this.$() would be available if jquery (or any jquery compat library) is available, but would not ship as standard and would not be used for core framework code.

@rtablada I would assume so as well, but assumptions are a dangerous thing. Better to call it out now than wish I had later.

Simply returning the DOM node would be enough, wouldn't it?

@jherdman No, this.$() should return a jQuery object for the element. Returning the DOM node directly would end up breaking any code using jQuery functions.

@ernesto-jimenez

This comment has been minimized.

Show comment
Hide comment
@ernesto-jimenez

ernesto-jimenez Apr 8, 2015

@weegeekps @rtablada @jherdman when the time comes, I'm sure the core team will do a graceful transition to remove jQuery, adding deprecation warnings to this.$ and maybe even starting a RFC if the change is significant.

Until then, we should probably keep this thread about deprecating IE8/IE9 in Ember 2 :)

@weegeekps @rtablada @jherdman when the time comes, I'm sure the core team will do a graceful transition to remove jQuery, adding deprecation warnings to this.$ and maybe even starting a RFC if the change is significant.

Until then, we should probably keep this thread about deprecating IE8/IE9 in Ember 2 :)

@tonycoco

This comment has been minimized.

Show comment
Hide comment
@tonycoco

tonycoco Apr 10, 2015

Does anyone have any data on government or the banking industry? I'd be curious to find out the percentages there as well.

Does anyone have any data on government or the banking industry? I'd be curious to find out the percentages there as well.

@nathanhammond

This comment has been minimized.

Show comment
Hide comment
@nathanhammond

nathanhammond Apr 10, 2015

@tonycoco I've provided out-of-band information to the included email address regarding banking.

@tonycoco I've provided out-of-band information to the included email address regarding banking.

@mgenev

This comment has been minimized.

Show comment
Hide comment
@mgenev

mgenev Apr 10, 2015

Drop IE8 and make Ember lighter please :)
And don't hesitate to drop IE9 too

mgenev commented Apr 10, 2015

Drop IE8 and make Ember lighter please :)
And don't hesitate to drop IE9 too

@zyllorion

This comment has been minimized.

Show comment
Hide comment
@zyllorion

zyllorion Apr 10, 2015

Please commit to maintaining IE8 / IE9 support for 1-2 years more. Yes I am serious.

We have numerous clients that have no published plans to move away from IE8 and definitely not IE9. We have no control over this, and these clients are worth significant amounts of revenue. We cannot use an unmaintained Ember for this length of time and will be forced to invest in another framework.

Ember offers something different to others, and the main thing is platform support. There are dozens of fancy frameworks offering the latest and greatest browser features and we are still a long way from auto-updating browsers in most corporate settings. Ember was chosen because it had a commitment to providing widespread support along with some internal knowledge, Angular specifically drops IE8 in 1.3 and ext.js did not have an existing knowledge pool for us to draw upon. A recent migration to ember-cli was essentially a re-write and that was a considerable investment.

So many IE haters are quick to say drop it, quoting percentages of IE users. Clearly they do not have financial losses by doing so, the only numbers that have any significance to business are monetary. I would ask that when calculating impact, the statistics do not include non commercial users. Few like developing for IE so platform abstraction that draws on a global knowledgebase is a key benefit of a framework.

My view is that if using Ember dictates OS dependencies then corporates will jump ship and use ext.js etc. If Ember loses support from those developers causing development to , will the hobbyists and trend-jumpers like the product so much?

Please commit to maintaining IE8 / IE9 support for 1-2 years more. Yes I am serious.

We have numerous clients that have no published plans to move away from IE8 and definitely not IE9. We have no control over this, and these clients are worth significant amounts of revenue. We cannot use an unmaintained Ember for this length of time and will be forced to invest in another framework.

Ember offers something different to others, and the main thing is platform support. There are dozens of fancy frameworks offering the latest and greatest browser features and we are still a long way from auto-updating browsers in most corporate settings. Ember was chosen because it had a commitment to providing widespread support along with some internal knowledge, Angular specifically drops IE8 in 1.3 and ext.js did not have an existing knowledge pool for us to draw upon. A recent migration to ember-cli was essentially a re-write and that was a considerable investment.

So many IE haters are quick to say drop it, quoting percentages of IE users. Clearly they do not have financial losses by doing so, the only numbers that have any significance to business are monetary. I would ask that when calculating impact, the statistics do not include non commercial users. Few like developing for IE so platform abstraction that draws on a global knowledgebase is a key benefit of a framework.

My view is that if using Ember dictates OS dependencies then corporates will jump ship and use ext.js etc. If Ember loses support from those developers causing development to , will the hobbyists and trend-jumpers like the product so much?

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Apr 10, 2015

Member

@weegeekps: We would definitely continue to support this.$() in components so long as jQuery was present. We rely on this heavily in our apps; even if Ember didn't require jQuery, I don't anticipate we'd drop it from Skylight.

Member

tomdale commented Apr 10, 2015

@weegeekps: We would definitely continue to support this.$() in components so long as jQuery was present. We rely on this heavily in our apps; even if Ember didn't require jQuery, I don't anticipate we'd drop it from Skylight.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Apr 10, 2015

Member

We cannot use an unmaintained Ember for this length of time and will be forced to invest in another framework.

just a heads up, I believe ember is the last of the big frameworks with official support for IE8.

Clearly they do not have financial losses by doing so,

I can appreciate this, but be mindful that Ember.js is built and maintained almost entirely by volunteers and to a lesser degree short term contracting engagements.

If there are financial motivations for some institutions maybe a paid LTS version for ember 1.x that continues to support IE8 can exist far into the future.

Ultimately this is a tricky balance. Of the maintainers no-one's applications are still supporting these older browsers, but we go back and invest considerable effort to ensure we maintain compatibility and reduce the potential of new features by reducing to what is technically feasible in an ES3 environment.

OSS works best when you are scratching your own itch. If old IE8 does actually represent a significant portion of our consumers then our active maintainers do not accurately represent this. If some form of support for IE8 is to continue to exist along the timeline @zyllorion suggest, we need (a|some) champion(s).

Member

stefanpenner commented Apr 10, 2015

We cannot use an unmaintained Ember for this length of time and will be forced to invest in another framework.

just a heads up, I believe ember is the last of the big frameworks with official support for IE8.

Clearly they do not have financial losses by doing so,

I can appreciate this, but be mindful that Ember.js is built and maintained almost entirely by volunteers and to a lesser degree short term contracting engagements.

If there are financial motivations for some institutions maybe a paid LTS version for ember 1.x that continues to support IE8 can exist far into the future.

Ultimately this is a tricky balance. Of the maintainers no-one's applications are still supporting these older browsers, but we go back and invest considerable effort to ensure we maintain compatibility and reduce the potential of new features by reducing to what is technically feasible in an ES3 environment.

OSS works best when you are scratching your own itch. If old IE8 does actually represent a significant portion of our consumers then our active maintainers do not accurately represent this. If some form of support for IE8 is to continue to exist along the timeline @zyllorion suggest, we need (a|some) champion(s).

@weegeekps

This comment has been minimized.

Show comment
Hide comment
@weegeekps

weegeekps Apr 10, 2015

My view is that if using Ember dictates OS dependencies then corporates will jump ship and use ext.js etc. If Ember loses support from those developers causing development to , will the hobbyists and trend-jumpers like the product so much?

@zyllorion As someone coming from a corporation that does software exclusively for the Legal & Finance sector (with Government contracts as well), I would be surprised if you have more than 10% of your customers left on IE8 who can't upgrade to IE9 or use a different browser with your product. Less than 10% and you're likely losing money if you continue to support the IE8 folks long term given the extra cost of maintenance required to support IE8's quirks. We've actually had quite a bit of success telling folks "use Firefox or Chrome if you have to keep IE8" with very little complaints. Occasional grumblings from lawyers but nothing significant as I understand it.

At the end of the day nobody benefits by continuing to support IE8. The browser is EOL'ed in January 2016, and apps that don't have the latest and greatest features tend to fail financially rather quickly these days, even for well established players in the sector.

My view is that if using Ember dictates OS dependencies then corporates will jump ship and use ext.js etc. If Ember loses support from those developers causing development to , will the hobbyists and trend-jumpers like the product so much?

@zyllorion As someone coming from a corporation that does software exclusively for the Legal & Finance sector (with Government contracts as well), I would be surprised if you have more than 10% of your customers left on IE8 who can't upgrade to IE9 or use a different browser with your product. Less than 10% and you're likely losing money if you continue to support the IE8 folks long term given the extra cost of maintenance required to support IE8's quirks. We've actually had quite a bit of success telling folks "use Firefox or Chrome if you have to keep IE8" with very little complaints. Occasional grumblings from lawyers but nothing significant as I understand it.

At the end of the day nobody benefits by continuing to support IE8. The browser is EOL'ed in January 2016, and apps that don't have the latest and greatest features tend to fail financially rather quickly these days, even for well established players in the sector.

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Apr 10, 2015

Member

One thing we should be clear about:

We are discussing making the last release in the 1.x series an LTS release. That means that, while it won't get new features, it will get critical bug fixes and security patches.

If you're in an enterprise environment that still requires IE8, you probably also want the stability and battle-testedness of the 1.x series anyway. Sticking with 1.x for enterprise environments gives you the best of both worlds: IE8 support and an API you know won't break.

This allows 2.0 to proceed at a much faster clip, and companies that do not have customers on older browsers will not have to pay a penalty. Even better, because of our strong commitment to Semantic Versioning, once you do drop IE8 (likely before Ember 3.0), you will be able to make the jump from 1.14 to 2.x without any backwards compatibility problems.

Member

tomdale commented Apr 10, 2015

One thing we should be clear about:

We are discussing making the last release in the 1.x series an LTS release. That means that, while it won't get new features, it will get critical bug fixes and security patches.

If you're in an enterprise environment that still requires IE8, you probably also want the stability and battle-testedness of the 1.x series anyway. Sticking with 1.x for enterprise environments gives you the best of both worlds: IE8 support and an API you know won't break.

This allows 2.0 to proceed at a much faster clip, and companies that do not have customers on older browsers will not have to pay a penalty. Even better, because of our strong commitment to Semantic Versioning, once you do drop IE8 (likely before Ember 3.0), you will be able to make the jump from 1.14 to 2.x without any backwards compatibility problems.

@2468ben

This comment has been minimized.

Show comment
Hide comment
@2468ben

2468ben Apr 10, 2015

@tomdale 👍 thanks for responding to all this, and discussing the possibility of an 1.x LTS.

2468ben commented Apr 10, 2015

@tomdale 👍 thanks for responding to all this, and discussing the possibility of an 1.x LTS.

@johnnyshields

This comment has been minimized.

Show comment
Hide comment
@johnnyshields

johnnyshields Apr 12, 2015

If ie8 and 9 can be supported by fastboot, good enough for me

If ie8 and 9 can be supported by fastboot, good enough for me

@yonjah

This comment has been minimized.

Show comment
Hide comment
@yonjah

yonjah Apr 13, 2015

From the many people commented here about there company still requires support of IE8, how many have actually using latest stable 1.x branch ?
At least from my experience Ember 1.11 IE8 support is too limited to be useful ( debug build completely breaks 10519, and alto core components work some tags might break components IE8 support 10520 )

I guess not being able to debug code without patching ember core is the most serious issue, but the fact that it's so easy to create a component that breaks IE8 support doesn't help much either.

Since our app targets enterprise clients we assume we'll have to support IE8 (we are still in the prototype stage), but I think ember 1.x had two conflicting declarations -

  1. pushing the web forward by aligning to standard like ES6 and Components.
  2. keeping support for IE8

I think if ember really want to help pushing the web forward dropping default support for IE8-9 is a must, but since ember promise to keep IE8 support there should be a straight forward way to opt-in for IE8.
I think keeping the 1.x branch LTS is a great idea but there are some thing that should have extra consideration when doing so -

  1. ember-cli latest should work with both versions, since ember-cli is the de facto way to build emebr apps, it should support Emebr 1.x branch and IE8 build even if 2.x doesn't
  2. addons should be built to support Ember 1.x and IE8, since this is generally up to the addon developer, official documents should make it clear where a feature or pattern might break Ember 1.x or IE8 support and what needs to be done to support both.

I think the ultimate implementation would be if you could load Ember 2.x for modern browser and Ember 1.x for IE8-9 for the same ember app, this will not only improve developing apps that support IE8 but will make the upgrade from 1.x latest to 2.x latest transparent

yonjah commented Apr 13, 2015

From the many people commented here about there company still requires support of IE8, how many have actually using latest stable 1.x branch ?
At least from my experience Ember 1.11 IE8 support is too limited to be useful ( debug build completely breaks 10519, and alto core components work some tags might break components IE8 support 10520 )

I guess not being able to debug code without patching ember core is the most serious issue, but the fact that it's so easy to create a component that breaks IE8 support doesn't help much either.

Since our app targets enterprise clients we assume we'll have to support IE8 (we are still in the prototype stage), but I think ember 1.x had two conflicting declarations -

  1. pushing the web forward by aligning to standard like ES6 and Components.
  2. keeping support for IE8

I think if ember really want to help pushing the web forward dropping default support for IE8-9 is a must, but since ember promise to keep IE8 support there should be a straight forward way to opt-in for IE8.
I think keeping the 1.x branch LTS is a great idea but there are some thing that should have extra consideration when doing so -

  1. ember-cli latest should work with both versions, since ember-cli is the de facto way to build emebr apps, it should support Emebr 1.x branch and IE8 build even if 2.x doesn't
  2. addons should be built to support Ember 1.x and IE8, since this is generally up to the addon developer, official documents should make it clear where a feature or pattern might break Ember 1.x or IE8 support and what needs to be done to support both.

I think the ultimate implementation would be if you could load Ember 2.x for modern browser and Ember 1.x for IE8-9 for the same ember app, this will not only improve developing apps that support IE8 but will make the upgrade from 1.x latest to 2.x latest transparent

@johnnyshields

This comment has been minimized.

Show comment
Hide comment
@johnnyshields

johnnyshields Apr 13, 2015

I'm planning to release a public-facing app that uses FastBoot. Until I read about FastBoot I was planing on using a traditional server backend, but FastBoot creates a new possibility I wouldn't have considered otherwise. As long as the "server mode" of FastBoot works on IE8/9 I'm happy even if the Ember JS itself never loads... I'm based in Asia and IE8/9 seems to be lingering here more than in US.

I'm planning to release a public-facing app that uses FastBoot. Until I read about FastBoot I was planing on using a traditional server backend, but FastBoot creates a new possibility I wouldn't have considered otherwise. As long as the "server mode" of FastBoot works on IE8/9 I'm happy even if the Ember JS itself never loads... I'm based in Asia and IE8/9 seems to be lingering here more than in US.

@sandstrom

This comment has been minimized.

Show comment
Hide comment
@sandstrom

sandstrom Apr 13, 2015

@yonjah just to chime in, our customers are all enterprise (of the old, conservative kind).

It's actually not a major issue to only support the recent version of IE (and if they really need to keep an old IE version, they are typically fine with using Chrome/Firefox in tandem).

If I were you I'd target IE 10 (or 11) plus. You'll save a ton of time and I don't think it'll affect sales.

@yonjah just to chime in, our customers are all enterprise (of the old, conservative kind).

It's actually not a major issue to only support the recent version of IE (and if they really need to keep an old IE version, they are typically fine with using Chrome/Firefox in tandem).

If I were you I'd target IE 10 (or 11) plus. You'll save a ton of time and I don't think it'll affect sales.

@yonjah

This comment has been minimized.

Show comment
Hide comment
@yonjah

yonjah Apr 14, 2015

@sandstrom A few weeks ago we decided were not going to keep testing IE8 for our first release, but there still very high chances we'll need to support it after the initial release.

We are targeting very limited and conservative audience so one client requiring IE8 support will mean we'll have to add support for it.

I hope your right but we wont be able to know that until we officially go online

yonjah commented Apr 14, 2015

@sandstrom A few weeks ago we decided were not going to keep testing IE8 for our first release, but there still very high chances we'll need to support it after the initial release.

We are targeting very limited and conservative audience so one client requiring IE8 support will mean we'll have to add support for it.

I hope your right but we wont be able to know that until we officially go online

@Panman8201

This comment has been minimized.

Show comment
Hide comment
@Panman8201

Panman8201 Apr 14, 2015

Speaking from the K-12 public education sector, it would be safe to drop IE8/9 support. At the school districts I've worked at we've been fairly flexible on installing browsers. Any computers holding onto IE8/9 due to other software needs typically have an alternate browser installed. In fact, most computers have an alternate browser installed anyway. So, +1 for dropping IE8/9. I'd hate to see it hold back Embers potential.

Speaking from the K-12 public education sector, it would be safe to drop IE8/9 support. At the school districts I've worked at we've been fairly flexible on installing browsers. Any computers holding onto IE8/9 due to other software needs typically have an alternate browser installed. In fact, most computers have an alternate browser installed anyway. So, +1 for dropping IE8/9. I'd hate to see it hold back Embers potential.

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Apr 14, 2015

Member

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.

Ecosystem

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

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.

Member

tomdale commented Apr 14, 2015

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.

Ecosystem

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

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.

@emberjs emberjs locked and limited conversation to collaborators Apr 14, 2015

Tom Dale and Yehuda Katz and others added some commits Apr 4, 2015

mmun added a commit that referenced this pull request Jun 7, 2015

Merge pull request #45 from emberjs/drop-ie8
Solicit feedback about IE8 and IE9 support in Ember 2.x

@mmun mmun merged commit 8774be9 into master Jun 7, 2015

@mmun mmun deleted the drop-ie8 branch Jun 7, 2015

mmun added a commit that referenced this pull request Jun 7, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.