drop IE support

[archmoj]

    @archmoj FWIW we just dropped IE support in Dash - and we did it in a minor https://github.com/plotly/dash/releases/tag/v2.7.0

I'd be comfortable doing the same in plotly.js, but open to discussing.

Originally posted by @alexcjohnson in #6355 (comment)

[archmoj]

See https://caniuse.com/?search=ECMAScript%206

[alexcjohnson]

For completeness, the decision we made in Dash was:

  "browserslist": [
    "last 7 years and not dead"
  ]

My rationale was that 7 years is the typical lifetime of a laptop, and there is likely a significant subset of users in very restricted environments who can't update their browsers even if they wanted to. And there's more for us to lose by breaking for those users than there is to gain from the performance and bundle size benefits of compiling to newer feature sets.

[raulmarindev]

Hello! I understand there are many other issues and this is probably lower priority than others. Would there be any possibility of allowing sponsoring for this specific issue? I'm looking forward to the performance and bundle size benefits 🚀. Thank you in advance!

[alexcjohnson]

@raulmarindev we'd be happy to discuss, but I'm curious, do you have reason to expect substantial size or speed gains? Our impression is yes both would improve but only a tiny fraction. My main interest in this is modernizing our syntax to make the codebase friendlier to developers.

[raulmarindev]

Hi @alexcjohnson, thank you so much for your quick response and, yes, your reasoning makes total sense. We love plotly at my company, and bundle size is really our only pain point with it. We use a custom bundle and load it through dynamic import, but it's still pretty big 😅. That's why any improvements in bundle size would be welcome.

Following your reasoning, I agree, the first step would be to update the codebase to use ES6 features. I'm willing to help with that if someone can point me to where to start. Again, thank you for all your great work.

[alexcjohnson]

OK great - if you're interested in helping get the process going, I think the first step would be to make a PR updating the config and tests and using modern syntax in a few parts of the code.

Re: config, looking at some of our other projects, plotly.js has a target:

plotly.js/webpack.config.js

Line 5 in ac2ce66

target: ['web', 'es5'],

that some of the others don't have at all, so we can likely just delete it. In package.json in other projects we set browserslist to ["last 8 years and not dead"] or some such, and that determines the output feature set. Then we have a test that currently verifies we're only publishing ES5:

plotly.js/package.json

Line 43 in ac2ce66

"no-es6-dist": "node tasks/no_es6_dist.js",

That's a very custom implementation, elsewhere we just use es-check so we can probably do the same and delete the custom script entirely. It's possible es-check just didn't exist when we wrote that long ago, or we didn't find it?

Unless I'm missing something, those changes will be enough to get dependencies using more modern syntax, at least if they're being distributed that way, which more and more of them are, and allow modern syntax in our code. But then the next piece is picking a piece of the plotly.js source code to update. I'd pick some reasonable-sized piece that's not currently being worked on, since a lot of lines will likely change and would create merge conflicts if another PR was active in the same file. Maybe something in components, like rangslider?

If we can do that much in one PR, it'll get the ball rolling and provide a template others can use to convert more of the code.