Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Merged
merged 2 commits into from Jun 7, 2015
Merged

Conversation

wycats
Copy link
Member

@wycats wycats commented Apr 4, 2015

RFC

@lukemelia
Copy link
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.

@cport1
Copy link

cport1 commented Apr 4, 2015

IE10+

@SebastianEdwards
Copy link

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

@ryanflorence
Copy link

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
Copy link

@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
Copy link
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
Copy link

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
Copy link

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
Copy link

nchase commented Apr 4, 2015

dropping IE8 and 9 sounds like a great idea.

@Pradeek
Copy link

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
Copy link
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
Copy link

Yessss. Kill it with fire.

@bradly
Copy link

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
Copy link

👍 for dropping

@opsb
Copy link

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
Copy link

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
Copy link

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

@ryanbillingsley
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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.

@ghost
Copy link

ghost 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
Copy link

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
Copy link

At Beatport, we only target IE10 and up.

@kencheeto
Copy link

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

@nanuxbe
Copy link

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
Copy link

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

@bakura10
Copy link

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
Copy link
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

@mupkoo
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

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

@nathanhammond
Copy link
Member

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

@mgenev
Copy link

mgenev commented Apr 10, 2015

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

@zyllorion
Copy link

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
Copy link
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
Copy link
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).

@weegeekps
Copy link

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
Copy link
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
Copy link

2468ben commented Apr 10, 2015

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

@johnnyshields
Copy link

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

@yonjah
Copy link

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
Copy link

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
Copy link
Contributor

@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
Copy link

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

@Panman82
Copy link

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
Copy link
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
mmun added a commit that referenced this pull request Jun 7, 2015
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 June 7, 2015 19:01
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.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet