WiKit is supposed to be used not only in new projects but also in already existing ones (Data Bridge, Termbox, Tainted References). As far as I know, those front ends support IE11.
The decision to drop support for IE11 in WiKit must only happen after we know we are dropping it for all of our products.

The decision should come from the Wikidata/Wikibase product managers. We (the developers) can provide PMs with a list of reasons why IE11 is hard to support but refrain from any other user-facing decisions.
I think the goal of this ticket should be to collect that list of reasons from the developers' perspective, so we can make the ticket actionable.
Otherwise, it will just sit on the board for a long time. Pinging @Addshore as the author. What do you think?

Just following up on Tonina's message and pinging @Lydia_Pintscher, since she was part of the original discussion: I agree that the Wikidata/Wikibase team should make explicit whether we uniformly abide by the Foundation's decision to only use the ES6 standard to implement new features, and thus we'll be dropping optimal support for IE11 (first for new features, and later for existing features and tools once their functionality is "replaced or repaired").

I would support keeping this ticket in case we want to include our own supporting arguments (as Tonina mentioned) in our response/agreement with the WMF's compatibility stance. Once our standpoint is documented, we could create a new ticket to "Drop IE support in WiKit" (and proceed with the technical task of removing the IE browser tests, and subsequently modify ADR 10).

A data point to prevent anchoring: the causality "only use the ES6 standard to implement new features, and thus we'll be dropping optimal support for IE11" (T178356's gist; @Sarai-WMDE is just the messenger) does not exist. It is only valid in a – somewhat artificial – universe where there is no way for a computer to help us (stern look at T199004).

However, for years, WMDE has been implementing in languages (e.g. TypeScript, less/sass) and using technologies (webpack, postcss) which allow us to have the development environment which makes us the most productive and have the browser support required at the same time – in this respect we can have the cake and eat it, too (with constraints, but those are not reached).

(This is not an argument for or against IE support, but an argument for asking the right questions and keeping discussion chains unentangled unless combining them provides a benefit)

That's a very important point, @wiese. My message reinforces a relationship of causality that doesn't have to be, not necessarily. There's always the chance to still provide support for IE, even if we're based on ES6, and deciding how to do so, at scale, might even help us avoid making decisions for specific browsers in the future. I forgot to link the notes from the last Front end standards meeting with WMF's Design system team, where the need to rely on progressive enhancement was mentioned while discussing the history behind this task.

My 2c from a rather different perspective.

Support for IE11 in WMF is in this weird stage of "no support for new products but keeping support for widely used/old interfaces" but it's not going to stay like this forever, we drop support for old browsers once a year or so, even if frontend-wise we don't push for dropping support, the platform of IE11 might lose support (e.g. due to TLS versions or ciphersuites it supports which happened with several versions of Firefox and IE9)

My biggest point is that we are currently using wikit for new features now and I assume (just assumption) by the time we reach rewriting the old UI with wikit, the whole support for IE11 would be already dropped by core. So I don't see the point of keeping IE support in wikit or tie it to core's support of IE11.

I understand this is a decision for WMDE, but I'd like to offer a little perspective from the WMF side of things.

I'd argue that we are reaching a point where retaining IE11 support is becoming costly enough to outweigh the benefits. @wiese is right that our lack of a front-end build tool makes things more difficult than they need to be (something I hope we can remedy soon). However, as the wider front-end ecosystem moves on, we will increasingly see places where the "compatibility gap" is so wide that even tools like Babel can't bridge it. Supporting IE11 will block (or at least complicate) our adoption of certain software.

One example is Vue 3. Vue's new reactivity features rely on Proxy objects, which just don't exist in ES5. Supporting IE will block us from upgrading to the latest version of Vue regardless of whether a build tool is used or not. (see here for a list of some of Vue 3's benefits)

Dropping IE11 support may also allow us to run a lighter-weight toolchain, even if we do end up adopting some build tools. Vite is a modern build tool that seems to have a lot of potential – additional plugins are required to support Vue 2 and to enable generation of ES5-compatible bundles.

I'm hopeful that we'll soon reach a point where WMF and WMDE can combine our efforts into a single component library (see T286946 and the upcoming developer summit). If we create a shared library and migrate our projects to that library, but remain on Vue 2, we will at some point have to go back and re-migrate things to Vue 3. Dropping IE support and moving to Vue 3 sooner than later may save us all a non-trivial amount of work in the future.

As of July 2021, IE traffic across all sites is down to 0.6%. Can we provide these users with an adequate no-JS experience to benefit the vast majority who don't use a legacy browser?

Just dropping in from T270510: IE browser tests are flaky on saucelabs [timebox: 1 day]

Is this something we want to invest time in?

One example is Vue 3. Vue's new reactivity features rely on Proxy objects, which just don't exist in ES5. Supporting IE will block us from upgrading to the latest version of Vue regardless of whether a build tool is used or not. (see here for a list of some of Vue 3's benefits)

@egardner do we already have some form of timeline for when we might end up using vue3?
At some point in the past year we did briefly discuss T273592: Migrate WMDE vuejs projects to vue3

On the whole the general direction this is going in makes me feel like we could close this ticket and also T270510 as it doesn't seem too flakey and annoying? and just wait for time to decide for us

In T285045#7247496, @Addshore wrote:

@egardner do we already have some form of timeline for when we might end up using vue3?

This is something we (WMF & WMDE together) can hopefully hammer out once we decide on T286948 at the upcoming Vue.js Developer Summit next week.