Is there a reason for all the pollyfills

[frank-dspeed]

Hi frinds as maybe some people know here i am recoding the whole code base of all modules in ESM syntax and i regonized many pollyfills all kinds of even for the most basic stuff implamented with NodeJS environment checks and all sorts of confusing code

what is the reason for that why don't this all get pollyfilled on build for lets say ie8?

even a array map pollyfill :)

[justinbmeyer]

It hasn’t been a priority. We will accept PRs that pull this stuff out. We can release it in CanJS 7.

[rjgotten]

Everything which uses can-symbol should atleast be fully retained.

The canonical solution practically everyone uses for transpilation is Babel. Babel relies on CoreJS for polyfills and the Symbol polyfill offered by CoreJS has unsolveable problems with IE11 when placing symbols on native prototypes. It is prone to cause infinite recursion that results in a stack overflow.

---

I might add; this is already a headache, as can-symbol and can-reflect both do not appropriately detect whether Symbol is the real native one, or the CoreJS polyfill.

I have two applications that are already facing this stack overflow problem and am having to currently hot-patch stronger detection into aforementioned two packages to force use of CanJS's own can-symbol polyfill.

[matthewp]

@rjgotten Would better detection around using the real Symbol solve your issues?

[rjgotten]

@matthewp

Would better detection around using the real Symbol solve your issues?

Yes. Which is what I'm current build-time hot-patching can-symbol and can-reflect for.
(I found a suitable detection btw. I will amend #5463 that I opened to track a fix.)

The downside is that I lose a working iterator symbol for DefineList and DefineMap that could otherwise be used together with the spread operator or loops, but that has very usable work-arounds.
(Also; ofcourse you only lose that symbol in IE. So nothing is affected in other browsers.)

[frank-dspeed]

i still opt for removing all prolyfills and also drop can-symbol complet use of symbols is ok but this module is not needed and makes trouble all over the place i patch it away also complet and replace canSymbol = Symbol everywhere i my self work with the new york times polyfill service polyfill.io sorry for so much typos but one of my eyes is destroyed at present i see everything doubled :D

[frank-dspeed]

and by the way can namespace should get replaced by can all or everything or something like that loading it and assign to it on export in every module is also a big problem always it makes much un needed trouble.

[rjgotten]

drop can-symbol complet use of symbols is ok but this module is not needed

I just gave you a use-case where it is needed.

Unless you accurately detect broken polyfills like the CoreJS one - which are sadly very standard - and avoid using them; you can trip bugs in them that can be quite catastrophic. Most of these bugs are endemic to attempting to provide a near-native polyfill of Symbol - and cannot or will not be fixed.

Because polyfilling often is automated nowadays, e.g. via Babel, developers also may be completely blind-sided by this problem suddenly popping up for them at the worst possible time. E.g. two weeks before a deadline, just as they were trying to integrate the last finished features.

So putting effort in to avoid that seems a good idea.
Ofcourse, needing to be able to avoid Symbol when it is badly polyfilled means you do need something else to plug the hole it leaves, and that's what can-symbol does do rather nicely. It's not a true polyfill - but it doesn't need to be. It just needs to do what it does so that CanJS as a framework can use it as a suitable enough substitute for its own machinations and keep things running.

[frank-dspeed]

Hmmm ok thats your opinion i see it out of a much higher level view it could be that it fits your needs or the needs of some people but it will not fill any needs in the future and i care about driving standards to libs that are often used. I am Also in the NodeJS Group for Old CJS Modules to help assist migrate to newer code. And CanJS is one of my Most Loved Projects for its spirit and ideas it has some really good parts but no one took time to design the high level view.

I Simply want to take it to the next level.

[SKFrozenCloud]

Polyfills should be the developers choice. With browserlist and core-js we should be able to polyfill the specified browsers.
Polyfills should not come in default. That is bad practice.

Also, supporting old browsers just because people still use them are bad practice as well. Just like IE6.

[rjgotten]

Polyfills should be the developers choice.
[..]

CanJS doesn't actually polyfill anything wrt publishing an actual Symbol. What it does is export a custom canSymbol for internal use within the framework, which can be the global window.Symbol, but failing that will be a facsimile tailored to what CanJS needs to function properly.

So in essence, it's not polyfilling anything. It's feature-sniffing and deciding whether it can 'go native' or not. Which is how things should work. The only matter that should be up for debate with that is imho, whether having this facsimile be part of the default builds is worth it.

Considering there's already a DEBUG pragma that can rip out unused code; maybe the whole thing should be hidden behind another pragma that can rip it out (or leave it included) depending on what the consuming application author needs.

[justinbmeyer]

The pragma is an interesting idea ...

[frank-dspeed]

@justinbmeyer i have still a lot of expirence in modernizing canjs i did over 5 years of research on this i could lift the code base up but i need to be sure that your on my side and that you accept the changes and discuess every opinion that you have because i come from a total diffrent side my main passion is ECMAScript tooling and out of that view i would love static analyzeable canjs as it is still the best framework it only needs a lot of chore updates. to make it more appeling to new users.

[frank-dspeed]

Really i am a Professional with more then 36 years of expirence that is a rare case i have diffrent views on diffrent things then the normal end user