PixiJS, IE 11 and the Future of ES6 #7109
Replies: 3 comments
-
Oooo, tricky. The problem I have with not transpiling to es5 is that it is still not a seemless experience for the user, when projects just exist as es6. I had an issue with one of SukantPal's sub-packages, for object pooling, and just, for the life of me, could not get Webpack to transpile just that one package into es5, despite having all the right settings. So that's a trade-off. Not transpiling makes it easier for us, but we will then get more issues from developers trying to integrate into their dev environment. It might be worth it! But I've had this very issue 3 months ago, and if someone experienced in this world struggled on this.... I can imagine a lot more will. Regarding polyfilling features - Internet Explorer is going to be a requirement still for a year or two, whilst paying customers are still there, but in this scenario, in my company, we already include the required polyfills via a Webpack plugin, so we don't need PixiJS handling it. And I think this is a reasonable route for PixiJS to take. And it's easy to detect existence of es6 in a short bit of code - https://gist.github.com/DaBs/89ccc2ffd1d435efdacff05248514f38 - so maybe we can just use that snippit and put a console message up saying that polyfills are required on this device? We could think about covering that off by recommending a polyfil service alongside using PixiJS? For example, something like |
Beta Was this translation helpful? Give feedback.
-
ooh! I am up for this! could we make it so that pixi legacy is es5 whilst the main package is es6? Also, would direct es6 output also help with tree shaking? |
Beta Was this translation helpful? Give feedback.
-
A consideration to how this change is handled, beyond just polyfills, is that it will be a breaking change for anyone who doesn't transpile their libraries but is using code that ends up in ES5 (including other plugins), since ES5 classes can't extend ES6 classes. In general, it's a good change to make, but needs to be handled carefully. |
Beta Was this translation helpful? Give feedback.
-
I was chatting with @SukantPal and we were discussing when the project might embrace ES6 more fully as the baseline for how we code and publish. For example, in Pixi’s source code we discourage the use of functions like
Array.prototype.map
and we also add polyfills for critical, well-used things likeNumber.isInteger
,Object.assign
,Promise
,Math.sign
, etc.Having to support ES5 environments makes it trickier to review code and harder to maintain the source, making it more likely that non-supported JS feature will make it through. Also, we transpile all source-code down to ES5, which adds some overhead to the output code.
Largely, these requirements are mostly (if not exclusively) about support for IE11 (the only lasting ES5 WebGL browser). Microsoft is dropping support for IE11 on August 17th, 2021. I think, we might want to consider phasing out all these polyfills and create a separate project or package to support pre-ES6 environments like IE11 (and probably some early Android version too). Also, in general, I'd like to see legacy-browser transpiling handled more by end-users. Or maybe we only transpile to ES5 for pixi.js-legacy package.
Thoughts? Ideas?
Beta Was this translation helpful? Give feedback.
All reactions