Atlaskit to drop support for Internet Explorer 11 from 1st July 2020

On 31st March 2020 we retired support for Internet Explorer 11 (IE11) in all Atlassian cloud products. From 1st July 2020 Atlaskit, Atlassian’s UI library, will also drop support for IE11. If you are a developer who uses Atlaskit please read on to find out how this will affect you.

Dropping support for IE11 represents a change to the contract of Atlaskit components (such as Editor, Elements, Media and Design System), so we will be releasing a major version of all packages on Jul 1, 2020. No code will change in this release. It will simply be an entry in the change log to signify that from that version forward the component will not be tested in IE11 and at some point in the future features may be used that will break in IE11.

What does this mean for you?

If you do not need to support IE11 you can continue to upgrade your Atlaskit dependencies as usual. As mentioned above this will be a zero-code-change release so consuming this upgrade will be trivial.

If you do need to continue to support IE11 you will need to stop upgrading your Atlaskit dependencies beyond the version prior to this one. There will be a clear message in the change log when the component drops IE11 support so keep an eye out for that. Atlaskit developers will have the ability to ship a patch to the last IE11-compatible version of a component in the case of any critical issues.

Thanks,

The Atlassian team

6 Likes

hi @jcrowe,

For a little while now Atlassian has been encouraging vendors to use Atlaskit for Server/DC development. This announcement puts us in a tricky position as we have taken that encouragement and now use Atlaskit in all of our server apps quite extensively. Our analytics shows that roughly 2% of our users are using IE11, and we believe that this is disproportionately biased towards our larger customers.

LTS releases mean that we have to support Jira 8.5 (EOL October 2021), Confluence 7.4 (EOL April 2022) and Bitbucket 6.10 (EOL January 2020) all of which still support IE11.

It is not tenable for us to not upgrade Atlaskit. There are bugs that will be fixed in Atlaskit that we want to pick up as well as new features. We also ship new features in our apps that support a wide range of host application versions. If we stick with the current Atlaskit version, we won’t be able to take advantage of updates, which will hamper our ability to ship value to customers.

Another point I’d like to make is making the announcement on the day that you drop support gives us no time to prepare. It feels like an after thought, it also feels like the impact of the change hasn’t been considered. I completely understand why dropping IE11 would be of benefit to the team building it, and we would love to drop it ASAP but the requirements that Atlassian put on us via the host applications supporting IE11 doesn’t give us that choice.

Please re-consider or put out something to customers stating that apps will not support IE11 that we can point them to when they contact our support.

Jon

11 Likes

The drop in support for Atlaskit IE11 was hidden in the IE11 announcement linked above further down in the thread, for this reason we knew about this from late last year and it was a bit of a surprise that IE11 support was not dropped at the end of march already. So it is incorrect to say that this announcement was not communicated in advance. Of course, there could have been a better way to communicate this.

Besides that, I wish there would not have been support announcement for the LTS releases as this forces us to target releases > Confluence 7.4 if we want to drop IE11 support from our apps.

1 Like

This is unacceptable.
CC @stephenmok

As @jmort also pointed out: you cannot first encourage us to include AtlasKit into Server, then release an LTS which is going to be supported until Dec. 17th 2021 that still supports IE (Jira), and then drop support for IE11 in AtlasKit.

This means that we are going to need to fork our code base and stop delivering new features & updates to customers. I will refer them to this message if they start asking why.

2 Likes

Will “critical issues” include cases where for example, a security vulnerability is found in a dependency?

When you are going to drop ie11 from babel config? It would be nice to get new smaller and more performant production bundle. There is a lot of bloat coming from having IE11 and ES5 as a target in your transpiler settings.

1 Like

By dropping IE11 support, what does that mean?

  • Atlaskit components will start using ES6 syntax that IE11 can’t parse?
  • Components can start using browser APIs that IE11 doesn’t have?
  • CSS features that aren’t available in IE11?
  • All or a mix of these?

If it’s about ES6 syntax, can the engines field be set for all Atlaskit components to mark >=Node 6 so that we can continue to transpile these components ourselves? We use GitHub - SamVerschueren/babel-engine-plugin: Webpack plugin that transpiles dependencies targeting Node.js versions newer than Node.js 0.10 for this, and I’m pretty sure it’s needed for some Atlaskit components today anyway.

If it’s about browser APIs, is there any reason that you can’t build the packages with @babel/plugin-transform-runtime and @babel/runtime-corejs3?

I have…no clue about CSS polyfills, so I guess that’s a wash.

Basically, if it’s not about writing IE11 compliant CSS, I don’t really see any reason that the components can’t still work in IE11 while restricting the development team.

I’ve just done a deep dive on these topics and how to roll these out for our own libraries internally, so I’m happy to explain any of this in more depth.

4 Likes

Hello folks, thank you for the candid responses. I hear the frustration this announcement has caused and I’ll do my best to address your concerns.

First of all let me apologise for not giving the community greater warning before we made this change. Although it was mentioned in comments in the original IE11 retirement post, I acknowledge that we should have communicated this more clearly given the impact of the decision. I also regret that we didn’t give the community a chance to respond to this decision before it was actioned. We’ll be sure to share decisions like this more proactively in future.

As for the decision itself, this was a tough one. By dropping support for IE11 we are able to take advantage of modern web features to deliver better experiences faster to the majority of our users. We have many teams inside Atlassian who will continue to support LTS versions of our Server products just like our ecosystem partners, and these teams - like your teams - must freeze their usage of Atlaskit. This is a tradeoff we had to make in order to balance building for Cloud while supporting our server teams and ecosystem partners. I can assure you that we aren’t asking you to make any sacrifices that we won’t be making ourselves.

To address a few of the specific questions in this thread:

Will “critical issues” include cases where for example, a security vulnerability is found in a dependency?

@mike1 yes any critical security vulnerability will be patched.

When you are going to drop ie11 from babel config? It would be nice to get new smaller and more performant production bundle. There is a lot of bloat coming from having IE11 and ES5 as a target in your transpiler settings.

@Grzegorz we already ship an ES2019 build of all Atlaskit components alongside ESM and CJS builds.

By dropping IE11 support, what does that mean?

@satvik it means all of those things so yes, it does include using incompatible CSS features.

Thank you everybody.

The Atlassian team

1 Like

I just love how the default behaviour of Atlassian is to do first and apologise later. Just a fair warning: keep doing this and you will completely deteriorate the Ecosystem. This isn’t personal @jcrowe, but you’re just the last one in a long long line of Atlassians following the same pattern, promising change, etc, etc, etc. I’ve heard it all before. Sorry, not buying it anymore. It’s fine, I’ll just sent an email to all our mutual customers on how Atlassian f*** us all again and how those pretty company values on the marketing website ring more hollow with every decision Atlassian makes. Let’s just stop pretend, shall we?

/end-of-rant

p.s. no worries, I’m currently just on one of my Atlassian love-hate relationship lows. There will be a love peak eventually, I’m sure. Being part of the Atlassian Ecosystem is a very bi-polar experience.

3 Likes

@jcrowe one more thing, and this is actually a more serious issue that you (and many other Atlassians) seem not to understand:

The problem here is that there is a difference set of expectations with customers regarding the LTS version of the host product, and the apps that run on it.

Customers know that LTS versions will only get security patches and they do not expect new features. Freezing atlaskit on these projects is relatively easy as there will be limited bug fixes on these products and changes that security vulnerabilities affect AtlasKit are slim.

The apps in the Atlassian Ecosystem works in an entirely different way. Customers continue to expect feature updates from apps, even though they are running on an LTS version of the host product. Apps typically do not release LTS versions as they provide smaller parts of functionality that do not warrant a code freeze.

Because of the Atlassian blindspot in regard to this different set of expectations, you consistently underestimate the impact & harm of these type of decisions. Which makes it even more infuriating that you do not seek council from the Atlassian Ecosystem beforehand.

I’m sorry if my melodramatic posts might cause you to miss the point, but it’s hard to keep giving constructive feedback to a company that continuously fails to understand why your failing to understand.

2 Likes

Hi Remie,
Thanks for the honest reply. I know that the past few years have been a lot of ups and downs and that Atlassian hasn’t done a great job at communicating with the development community.
I don’t want to make empty promises that there will be radical change right away this fiscal year, but I do want to point out that we now have a dedicated Marketplace Programs team that is growing. Among them are people like me, a Technical Partner Manager. This is new, never done before at Atlassian.
We are like the TAM team is to Enterprise customers. We are your champions inside Atlassian.
We listen closely to feedback, we collaborate on efforts internally to improve our relationships with the development community and the Marketplace Partners.
We are a small team, but very motivated professionals who are determined to get sh#t done, for you all.
Hopefully, you won’t see this as an empty promise or fluffy talk, but as a message from a trusted advisor who has your company’s interests at heart.
We hear you. We’re dedicated to helping you.
If you don’t believe me, ask around and see if we are true to our word :wink:

3 Likes

@Miro.Capka Will there be an overall new Major version of AtlasKit components for all Components that do not support IE11 anymore?
Currently the versions of many components are not aligned. How can we know that Button v10 still Supports IE11 but Button v11 does not? Will there be a versioning scheme that will be enforced?
Like Angular does it with its major versions counting up for all components?

1 Like

@clouless yes we recently released a major version of all components to communicate that they will not support IE11 from that version onwards. Our components are versioned independently so the specific version number that this happened in will be different for each component. This is communicated clearly in the changelog, e.g.: Atlaskit by Atlassian.

1 Like