So effectively, you're arguing that stagnant tools should hold back evolution of the language, even when non-stagnant alternatives exist?
On Tue, Feb 12, 2019 at 3:26 PM kai zhu <[email protected]> wrote: > > Can you expand on what you mean by this, or provide an example of a > > feature that can't be "easily minified”? > > fat-arrow/destructuring/es6-classes comes to mind. if you have legacy > build-chain that doesn't use babel or terser, is it worth the effort to > retool the minifier to support these syntaxes so you can use it? also any > feature which introduce new symbol/symbol-combo which requires re-auditing > minifier's regexp-detection (private-fields, optional-chaining, etc.). > > there’s also the argument using babel in minification-toolchain defeats > the purpose of reducing code-size. > > > On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr. <[email protected]> wrote: > > > > On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[email protected]> wrote: > >> i think there’s an industry-painpoint (at least from my experience), of > resistance adopting es6+ features because legacy-toolchains cannot be > easily retooled to minify them. > >> > >> i’m not sure the best way to address this problem? i favor requiring 2 > independent minifiers to be able to handle a stage3-proposal before > advancement (indicating retooling is feasible), but that may be > overly-restrictive to some folks. > > > > Can you expand on what you mean by this, or provide an example of a > > feature that can't be "easily minified"? > > > > ~TJ > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
