emberjs
Optional chaining not supported by UXP/GRE browsers, causing issues
It seems you've started using ?. optional chaining (instead of null checking) in ember.js which is causing a lot of problems for UXP/GRE browsers like Pale Moon, Basilisk, Borealis, and various forks. While we are working on implementing this, it's a fundamental parser change and has proven to be very tricky/elusive to make work.
Some high profile websites are now switching to versions of ember.js that use optional chaining (e.g. mewe.com) and this is breaking the web for us.
Could you please consider using normal null checking instead, or providing fallback code that doesn't use this shorthand?
Ember.js projects use Babel and browserslist to transpile code to match a defined feature-set and support matrix, which as of now only covers the most commonly used "evergreen" browsers. All current transpilation targets support optional chaining. A previous set included Internet Explorer for production builds which didn't support optional chaining either and as a side effect resulted in builds that also run in Pale Moon.
There was a RFC process for this change, but from a quick glance I didn't see anyone objecting in favor of small scale browsers, which is an oversight that needs discussing.
Personal opinion: I'm not entirely certain how this is the responsibility of the framework.
I'm not sure in what way your reply addresses this aside from "Oh we should have thought of that but didn't". Are you proposing anything? Is this something that has to be passed up to the transpiler if that's not your responsibility? Although I'd guess that this comes down to a configuration of the transpiler used, if I look at your "matrix" which isn't really much of a matrix just what is considered the webkit/blink + gecko pair.
Personal opinion: I'm not entirely certain how this is the responsibility of the framework.
Isn't is the responsibility of a framework to be browser-agnostic?
Especially if you are looking at the current duoculture of Google and Mozilla (with the latter being fully funded by the former), taking alternative web browser engines into account (small or not) should be important. Just going by "last-1 Chrome, Firefox, Safari" clearly excludes the one main alternative that is left and actively developed. As a framework developer you should be even more responsible because any web compatibility influencing change made in it will impact hundreds or thousands or more websites that rely on a framework.
I suggest you configure your transpiler to continue including internet explorer compatibility if that is the only way in its current form that Pale Moon and other browsers will be supported by the many websites using ember.
Which browser to support, is a choice made by each project/site not by Ember.
Turns out is also not that much of an oversight, but an opinionated decision. The Ember website contains a very public document on Browser Support.
I agree with @bracke, this is not a framework problem. Not that my answer matters in any fashion. I'm a user, not the brilliant team who maintains this framework. I merely pointed out that the framework actually provides tooling that allows users of Ember.js to make a conscious decision to support niche or legacy browsers.
I'm sorry, but your config in your framework has been set to not be compatible. I agree that that's been an opinionated decision. What do you think happens when your defaults are limiting? Do you think every website out there will start to explicitly reconfigure something they may not even be aware of? No, they will instead tell visitors to "use a supported browser". The "supported browsers" for those websites will be equal to whatever the default is for the frameworks that are being used.
So, whose decision and responsibility is this then? Why isn't this a framework problem? Why aren't you by default configuring ember.js to be very broadly compatible? I hope you understand where I'm coming from here.
@wolfbeast palemoon fully supports es2017, right ? if so, i think that would be a good default preset for babel to support all browser still maintained. it also runs in half of the time as es2015 preset (using node.js) and produces only marginally bigger code than targeting latest ecmascript.
palemoon fully supports es2017, right ? if so, i think that would be a good default preset for babel to support all browser still maintained. it also runs in half of the time as es2015 preset (using node.js) and produces only marginally bigger code than targeting latest ecmascript.
Pale Moon indeed supports all parts of es2017 and es2019 (at least according to kangax tests) and has partial support for es2018 (missing the Google irregex extensions) and es2020 (everything except BigInt, ?. and ??). default preset to es2017 should definitely provide broad coverage of maintained browsers without going into very fine granularity.
No longer relevant as Pale Moon and other UXP-based browsers now support optional chaining.