Upgrading PixiJS to ES2016 and beyond #8454
Replies: 2 comments 1 reply
-
These are all fair points. In general, the project has not been historically bullish on new browser or language features. Having to support new features with polyfills has been a pain. Also, PixiJS has a long history of trying to go a wide as possible (hence the canvas fallback). Bleeding browser features typically don't get it or take awhile, including new language features. That said, shipping ES2020 is not necessarily a huge win for us, the file-size differences seem pretty marginal. Maybe there are some performance improvements without transpiling backwards as well? We've already started using ES2020 features in the source code (optional chaining, nullish coalescing), so it's very little effort to change the target in the tsconfig. ES2020 sound reasonable, but I'd love to hear some more feedback from folks on this topic. Personally, I'd rather have developers transpile Pixi to whatever target makes sense for them. Seems like a better separation of concerns. |
Beta Was this translation helpful? Give feedback.
-
In my projects of the past few years where I do have to support older browsers, I have found that targeting ES2017 for my build output has been fine. However, I think that really only matters in places where you aren't using build tools to downlevel your JS apis and insert polyfills - in theory the module output could target a newer version than the browser bundle as long as we document that and inform users what polyfills/minimum tool versions they may need. |
Beta Was this translation helpful? Give feedback.
-
📣 Overview
ES6 (2015) is a huge step forward compared to ES5 (2009).
PixiJS v7 will target ES6, but why not upgrading to ES2016, 2017 or even newer version?
I undestand the need of backward compatibility for old browsers, but since Edge's transition to Chromium in 2020, there are only 3 major types of browsers:
All actively pushing new releases every year, which makes it easier to upgrade to new features.
🧪 Build tests
I tried to build PixiJS using the
next
branch.Here is the weight of the
/bundles/pixi.js/dist/browser/pixi.js
file:es5
: 2.24MBes6
: 2.09MBes2016
toes2019
: 2.06MBes2020
&es2021
: 2.05MBes2022
: did not build (rollup doesn't recognize es2022 yet)✨ New features
Here are some of the cool new features:
es6
:...
operatorfor of
loopses2016
:...
operator**
operatores2017
:es2018
:...
operatores2019
:es2020
:?
??
es2021
:es2022
:ES2022 was released just a week ago, it is already supported by TypeScript but not yet supported by Rollup.
🔌 Browser compatibility
Kangax's Compatibility Table, is a great tool to find browser support for ECMAScript features.
According to
Can I Use
:es6
represents ~96% of the global usage (by dropping Internet Explorer, Safari < v11, Edge non-chromium-based and other old browsers)es2016
represents insignificant differences withes6
es2017
represents insignificant differences withes2016
es2018
represents ~95.5% of the global usage (the most significant changes would be to drop Safari v11)es2019
represents insignificant differences withes2018
es2020
represents ~93% of the global usage (the most significant changes would be to drop Safari v12 & v13)es2021
represents ~92.2% of the global usage (the most significant changes would be to drop safari < v14.5)es2022
represents ~86.2% of the global usage (the most significant changes would be to drop safari < v15.4 & Samsung Internet v15 & v16)While it is clearly too early for
es2022
(Safari 15.4 was released on March 14, 2022),es2019
,es2020
&es2021
are great candidates as PixiJS' new build target.⚙️ Node.js compatibility
As for the upcoming Node.js support:
v14
supportses2019
and almost alles2020
features (and has less than a year before its support is dropped)v16
supportses2021
v18
supports almost alles2022
features(cf. node.green)
💭 My opinion
IMO, PixiJS v7 should target ES2020, as it is becoming the new "standard" for modern projects (e.g. since May 2022, Angular now targets ES2020).
Beta Was this translation helpful? Give feedback.
All reactions