Ember 4.0

[Gaurav0]

Let us set up a timeline for Ember 4.0 in order to be able to drop support for IE11.

[Gaurav0]

For reference: https://blog.emberjs.com/2017/10/03/the-road-to-ember-3-0.html

[NullVoxPopuli]

Update (2020-03-31) -- I've changed my mind on this.

A bunch of these things are mostly independent, and fall in to 4 categories:

• deprecation removal / legacy removal
  • this is what major versions are for
• I want a feature that other ecosystems have
  • embroider, etc
• I want a feature that is unique to ember and would be super cool
  • binary templates, automatic bundle splitting, etc
• I no longer want to deal with the awkward parts of ember, and would like ergonomic replacements
  • controllers, query params, template imports, etc

I think pushing for everything below before cutting a 4 release would cause the opposite of what people want: giant byte bloat.

---

Things I would like to see landed before Ember 4:

• embroider
  • tree shaking
• option to have no controllers
• typed templates
• template imports
  • ability to have components anywhere
  • file/project linter to enforce component locations.
• binary templates
• information on GlimmerVM as WASM (was this a good idea?)

All of this might be too far out there, but also, It could warrant another edition.

If Ember 3 is carrying too much bloat with it, I'd be cool with a bump to 4. However, because everyone is really slow at upgrading, I think we'd want to wait at least a couple of LTSs.. Maybe once 3.24 is LTS, it'd make sense to do Ember 4.0, and remove all the cruft from the pre-octane era

[Gaurav0]

Why should we continue to support IE11 for another year or two while all that is being done? IE11 support is actively holding us back from using features like proxies and requires us to ship polyfills.

[NullVoxPopuli]

tbf, IE11 is holding everyone back that needs to support it.

[lifeart]

IE 11 supporting may be opt-in feature with some codestyle limitations.

[makepanic]

As an alternative to dropping IE11 one could also investigate what other frameworks are doing with Differential Loading that splits the build output into a evergreen and legacy bundle.

This allows newer browser to get a small payload while older browsers can still work by loading more javascript.

There's also the possibility of letting the developer handle old browsers themselves by making polyfills easaier to load, see e.g. polyfills.ts in NG2.

This won't work if ember uses API that isn't possible to polyfill though.

[Panman82]

I might be wrong here, but I think there are newer things that cannot be polyfilled and therefore (once used) will forever break backwards compatibility with IE11.

FWIW, I'm in support of dropping IE11 support. This could also be a more direct question on the upcoming survey for EmberConf.

[pzuraq]

Certain features, such as native Proxy, are impossible to polyfill, and so the framework cannot use them for many production features. I think the ability to use Proxy would be incredibly helpful, and definitely should factor into the timeline.

I do think we should consider adding the Babel polyfill by default prior to dropping support for IE11, specifically so libraries and Ember can begin to adopt some feature now and smooth out the transition. The number one feature I can think of is native Symbol, which is the future for how custom iterables will work in Ember in the future (and would allow us to deprecate certain obscure behaviors of {{each}} and EmberArray/ArrayProxy).

Overall, I’m in favor of a faster timeline, especially now that Edgium has been released with IE11 compat mode.

[chriskrycho]

@NullVoxPopuli

Things I would like to see landed before Ember 4: …

This is actually pretty much the opposite of how we've learned to approach majors in Ember—that is, in dropping deprecated functionality. Nearly every one of those could land on any old minor version, and few of them besides controllers even have any relationship to removal of deprecated code. (And controllers aren't yet deprecated!)

Dropping IE11 support (as well as trimming a lot of defunct code elsewhere) is a high-value reason to bump to 4.0. Nothing says we can't do a 5.0 a year or 18 months later (or six months, for that matter, depending on how things shake out!). And we'll just keep incrementally delivering features along the way.

[NullVoxPopuli]

Cool. I was under the impression we were staying on 3 for as long as IE11 exists. :)

[chriskrycho]

IE11 will exist until Windows 10 is dead (which is a long time from now); IE11 will not be recommended or supported by Microsoft in that timeline, however; the Edge-on-Chromium replacement includes an IE11 compatibility mode to allow enterprise organizations which have IE11-only intranets and other internal software which requires and only runs on IE11 to work in Edge, which they've back-ported to Windows 7. (This is what @pzuraq was referring to above with his comment about "Edgium… with IE11 compact mode".)

Most likely, Ember can therefore safely drop it at some point later this year (or at latest in early 2021, I'd guess). The specifics will depend on how major ecosystem players' needs shake out, and what timeline Microsoft pushes for, but IE11 support can go away some point sooner rather than later. 😅

[NullVoxPopuli]

Most likely, Ember can therefore safely drop it at some point later this year (or at latest in early 2021, I'd guess).

This is wonderful news.

Then yes, I'm a on board with the aggressive major version bumps to clean up deprecations. :)

[NullVoxPopuli]

Oof. I'm a potato today.

Just realized the deprecation of IE11 has absolutely nothing to do with the other deprecations and the eventual version 4

[gossi]

What I like for ember in majors it is dropping deprecated APIs and in following semver is able to adjust the supported environments (eg. node and browsers) - am I right? Then this information is missing for me:

The list of dropped APIs:

• https://deprecations.emberjs.com/v3.x

-> Is this list "enough"? In terms of whether one or another API should be deprecated before in order to ... ? In order to achieve something or prepare ember4 to be capable of ... ? (please fill in the blanks)

The newly supported browsers:

• ???

Node

• ???

IE11: Personally I'm super happy to drop it as it suggests slimmer builds. On the other hand at work we have to support IE11. Even though MS emulates older browsers in their newer ones, that does not necessarily mean intranets or their IT landscape will update to them. For those environments IE11 is often strongly coupled to it. Just want to raise awareness for this and definitely not advocating to keep IE11 support. Maybe ember3 will become the IE11 version and ember4 the modern version. The thing I'm worried about then is to new changes aren't available consumers that are stuck with supporting IE11 and whether this is creating a gap within the ecosystem of addons, etc.

Don't click this link: https://death-to-ie11.com/

[Gaurav0]

@gossi For how long does your company need to support IE11?