[01:16:44] mszabo: FYI, Fandom mentioned at https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md [09:20:19] Krinkle: Heh. Yeah that library has a bus factor of one [09:28:17] looks like we only use it in something that only loads for anonymous users though [13:11:04] mszabo: presumably result of something that is webpack/babel'ed? [13:11:32] specifically with settings that allow newer features than MW guruantees. [13:11:46] Krinkle: yeah, I think it is used by lazy-loaded experiments code that is only fetched for anonymous users, it's from outside MW [13:11:50] (which even the odd MW project that uses Babel, like mwext-Popups, doesn't do.) [13:11:58] ah okay, that makes more sense [13:12:22] Bloomberg takes the cake with 50 copies of core-js though [13:12:30] that takes a special kind of ignorance to pull off [13:12:42] I think the main takeaway for me is... do the perceived developer benefits of ES6 warrant shipping a big polyfill to non-ES6 browsers, and, if non-ES6 browsers need not be supported, is it worth shipping a polyfill to smooth over "inconsistencies" in the implementation [13:13:13] es6-polyfill and web2017-polyfill come with MW core and don't load in modern browsers [13:13:30] so largely a solved problem if you're willing to use them through ES5 syntax [13:13:50] yup [13:14:02] I specifically wonder how much "But even the most modern engines do not implement the most modern JavaScript features. Even the most modern engines contain bugs. Are you pretty sure that you and your team perfectly know all limitations of all engines that you support and can work around them? Even I sometimes may forget some moments." is a real issue [13:14:19] since that's what core-js purportedly solves in an es6-only context [13:15:06] a kind of counterpoint is that CSS likewise requires developers to be aware of browser specific implementation quirks, for which AFAIK there is usually no "easy" solution [13:15:06] All I can say is, in 15 years on the web I've never once been bitten by a spec incompliancy outside DOM APIs. Not with ES3, ES5 or now with ES6 methods. [13:15:17] and we had plenty of surface area to trigger it with RL and VE. [13:15:20] yeah, I kinda feel that some of these are edge cases made to seem larger than real life [13:15:52] so then the question would be - does the business risk/potential user impact from such a bug outweigh the potential risk/extra cost from including a big polyfill [13:16:05] specifically a big polyfill with bus factor = 1 and an uncertain future... [13:16:41] caniuse and MDN are pretty good about warning you against bugs for web APIs, and that seems worth the cost to ocasionally check compared to shipping what he describes (imho, correctly and deservedly) as essentially a whole headless browser runtime. [13:17:04] but yeah I can imagine the "React" generation is pretty excited about being able to ignore it completely and ship it down the user's throats. [13:17:09] this is my feeling as well [13:17:40] but even they are likely subject to various bugs that are missed from not upgrading the library in time, or from something that hasnb't been reported, or one of the 100s of APIs not covered by core-js where imho most bugs are. [13:18:35] especially now that people seem to avoid jQuery, they're gonna run into more bugs, as we've seen e.g. at WMF a few times in mobile frontend and minerva code, adoption of plain JS with e.g. some new classList method or Promise method not existing and causing fatals in IE11. [13:20:05] yup, that's a risk without a static analyzer or linter warning about it [13:20:30] I will say though, core-js is a pretty good source of polyfills, which we do use in MW (we use a different source though). For that purpose, it's pretty solid, and I don't think the shit thrown there is deserved either. The post makes a lot of solid points that are very much reflective of FOSS today. [13:20:59] Financial-Times/polyfill-library is a pretty good source as well, we use that for the URL API which I made some upstream contributions to. [13:21:20] but for ES polyfills, there aren't many good sources indeed. FT mainly focusses on DOM. [13:22:00] yeah - it's sort of forcing a discussion about the costs/benefits of including a polyfill and what's appropriate, which I think is fair [13:22:11] I wouldn't be surprised if a lot of core-js usage was just implicit [13:22:36] I mean he could've been the maintainer of eslint or grunt or phpunit, and a similar story and case could be made. [13:22:58] It's not obvious to me that this is an issue specific to projects we believe aren't needed. [13:27:41] yeah, the overarching point is basically OSS stewardship/funding [13:28:03] the polyfill bit is specific to corejs ofc but broadly it does show how many oss projects we take for granted