You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
@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.
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.
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:
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:
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.
Activity
[-]dropped IE support[/-][+]drop IE support[/+]archmoj commentedon Nov 11, 2022
See https://caniuse.com/?search=ECMAScript%206
alexcjohnson commentedon Dec 14, 2022
For completeness, the decision we made in Dash was:
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 commentedon Jun 7, 2023
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 commentedon Jun 8, 2023
@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 commentedon Jun 11, 2023
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 commentedon Jun 12, 2023
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
that some of the others don't have at all, so we can likely just delete it. In
package.jsonin other projects we setbrowserslistto["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
That's a very custom implementation, elsewhere we just use
es-checkso we can probably do the same and delete the custom script entirely. It's possiblees-checkjust 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, likerangslider?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.
[-]drop IE support[/-][+]clean up IE 11 support[/+][-]clean up IE 11 support[/-][+]clean up remainings of IE 11 support in v3[/+]