chartjs / Chart.js

Simple HTML5 Charts using the <canvas> tag
https://www.chartjs.org/
MIT License
64.56k stars 11.9k forks source link

Is IE11 still supported in V3? #8042

Closed stockiNail closed 3 years ago

stockiNail commented 3 years ago

I am testing the samples of version 3 of master and going to the vertical bar sample, I have got the following error, by IE11:

SCRIPT438: Object doesn't support property or method 'values'
chart.min.js (13,60262)

Maybe I'm wrong but it seems IE11 is not supported anymore.

kurkle commented 3 years ago

It should still be supported, because the support has not been dropped.

Object.values is used here: https://github.com/chartjs/Chart.js/blob/7718d5fd56e14ac26af14f8c74aaeb5cbfcd32ee/src/core/core.controller.js#L1076

It comes from #7843

LeeLenaleee commented 3 years ago

Legacy browser support gets dropped in V3 right with this pr #8009 ?

Also IE support from ms will end in less then a year so I think this is the perfect time to drop support for legacy browsers so you can use new features like optional chaining in the future if it comes out of draft

etimberg commented 3 years ago

If we can drop IE11 support now, I am onboard.

stockiNail commented 3 years ago

If we can drop IE11 support now, I am onboard.

I could agree but you must be aware that in the enterprise world IE11 is still hugely used, therefore, for me, to drop IE11 is not a good decision

kurkle commented 3 years ago

https://www.google.com/amp/s/cisomag.eccouncil.org/no-security-updates-to-ie-browser/amp/

stockiNail commented 3 years ago

https://www.google.com/amp/s/cisomag.eccouncil.org/no-security-updates-to-ie-browser/amp/

Yes @kurkle, I'm aware. I'm not sure that all companies will jump on Edge but nevertheless they can use FF or Chrome :). Let me highlight that I'm not against to drop IE11 but I know companies which are still using IE11. Dropping IE11 I could also think to remove polyfilling...

LeeLenaleee commented 3 years ago

@stockiNail interesting point but if they want to keep using IE11 they can still use charts 2.9.4.

With a major upgrade like this it's the best time in my eyes to drop support for outdated browsers so that you can use new js features in your code whenn they come out.

Otherwise you will need to wait till version 4 because I think it'd weird to say it's only supported till v3.4 for example

stockiNail commented 3 years ago

Guys, you have convinced me! it's right time to do it, I agree! Let's drop it! Just mentioning in the migration guide.

kurkle commented 3 years ago

Updated #8009 to mention the removal of IE11 support (and also remove the really old version numbers of other browsers)

xr0master commented 3 years ago

I agree with @LeeLenaleee if large companies can't update the browser, they probably won't update the code either. They can continue to work with chart.js version 2.

cayuu commented 3 years ago

tl;dr: 1. dropping IE11 is fine if providing ES5 build targets. 2. IE11-support mandate is modern and current reality for many markets inc. larger orgs/governments (i.e. even a brand new startup using the hottest dev stack and doing CI deploys 50 times a day may still need IE11-support when servicing these markets)

... if large companies can't update the browser, they probably won't update the code either.

For the record, as a counterpoint, this is flat out wrong.

"Let them eat the old version" is a common refrain, but it's misplaced. To add a datapoint from the context you're talking about (large org finance, markets, and now government) it's actually more like the devs in those spaces have to seriously push the envelope by hunting for performant, cross-platform solutions (so things like the performance upgrades in Chart.js 3 are absolutely reason to upgrade).

Governments and large orgs often have requirements if not outright obligations to support much broader userbase needs (and often much larger audiences) than startups or individual developers and the IE11 requirement is usually an external/environmental/legislative constraint that complicates QA and build/test/CI pipelines, not an indication that they don't or wont "update the code".

I'm not sure that all companies will jump on Edge

Yep, 100% correct. And the bigger the company the less likely the jump. But for governments it's also about supporting their end-users in "accessible" ways and that means supporting "supported" browsers.

Also IE support from ms will end in less then a year

Sadly, nope. IE11 is supported until at least Oct 2024 😢 (the EOL support for Win10) -- I do expect large orgs and governments to painfully migrate as we approach that date, but i'm not holding my breath. MS is winding down support for their webapps for IE11 from this year, but that's not the same thing.

Nonetheless, dropping IE11 support from the codebase is actually fine.

It's common practice these days to have to conditionally polyfill back for IE11 in order to support "the new shiny". However lib authors can enable this process by providing ES5 transpiled targets as part of package deploys.

Just 5c from the other side.

xr0master commented 3 years ago

I just can't agree.

How many of your target customers are using IE11 that you are so worried about supporting it? If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.

ES5 will add weight to the library, few people need this support, but everyone will suffer. These people can continue to work with version 2, if they need to support IE11.

Beginning November 30, 2020, the Microsoft Teams web app will no longer support IE 11. Update: The Microsoft Teams web app no longer supports IE 11 as of November 30, 2020. To access Microsoft Teams, use the desktop app or a supported modern browser like the new Microsoft Edge. Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

source

cayuu commented 3 years ago

I just can't agree.

I get that. This is why I posted. Because unless you work with large (non-tech) orgs or in government, IE11 support seems insane. But outside the "tech world", IE11 support comes up way more than you'd expect (or ever want).

How many of your target customers are using IE11 that you are so worried about supporting it?

Case in point: for us, comfortably 80% of our clients either use IE11 or require us to support it, including every Federal government agency we deal with and most State level too. It's only at local government levels that IE11 is a nice-to-have. Governments in many countries have accessibility legislation (real laws, with real consequences) that in some cases more or less require them to support "supported" browsers. In most cases, these requirements are flat out non-negotiable.

If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.

You're not wrong, but I'm not sure you've dealt with large orgs or government before? It's not that this conversation can't happen, but in many cases their fundamental requirements preclude this. It's a non-starter.

Which means it remains a "sun rises in the morning" fact that there are locked-in-stone requirements to support IE11 that are not going away until late 2024 and probably beyond that. I don't like it either.

Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

Yep, that's exactly what I said earlier. But as I also said, it's irrelevant. MS is sun-setting their own internal web-app support for IE11, but that's not the same thing as sun-setting support for the browser, so doesn't change large-org/gov requirement sheets. IE11 itself is supported until EOL Win 10 which is currently Oct 2024, and large orgs and gov (and therefore apps built for userbases of millions) will also have to support it. Yeah it's a total sh1t sandwich.

These people can continue to work with version 2, if they need to support IE11.

Except that's not how it works in practice.

Depending on the project, you can be talking about userbases of hundreds of thousands of people that don't show up on the open internet (internal agency or inter-gov apps). In other cases, IE11 support is mandated for public apps that serve millions of users. Which means if you cripple your codebase to comply with the "sorry, you must just eat the old versions of dependencies", you cripple it for everyone.

So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely. But that beats the hell out of the "just eat the old version" mantra while we wait for IE11 to properly die.

few people need this support

Yeah this is why I posted. It's more people than you think. And often with much bigger audiences than you imagine precisely because it is large-orgs and government, which is precisely why it sits in the blind spot of so many devs.

As may be the case here if it goes that way, for reference, for the few dependencies we use that don't provide ES5 bundled deps (and to be clear, a very large number DO provide this), we end up vendoring the code into custom build pipelines that end up going through our own transpile processes to ensure they are broadly accessible. It's a pain but c'est la vie.

TL;DR remains: dropping IE11 support is fine. IE11 is officially around until Oct 2024. And it's a really nice move to provide an ES5 build.

kurkle commented 3 years ago

So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely. But that beats the hell out of the "just eat the old version" mantra while we wait for IE11 to properly die.

That how I'd do it. Write a modern thing (with modern libs) and transpile to ES5, all of it. Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

cayuu commented 3 years ago

Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

Exactly correct.

cayuu commented 3 years ago

For anyone finding this down the line, Chart.js officially breaks up with IE11 permanently as of PR #8374 (included as part of the v3.0.0 gold release) due to the use of proxy Reflect calls in ways that cannot be polyfilled to work in Internet Explorer. End of the road.

MaxboDev commented 3 years ago

It looks like this isn't mentioned in the migration guide. It seems like it should be somewehere very prominent.