add stage4 constraint - ease-of-minification

kai zhu kaizhu256 at gmail.com
Tue Feb 12 23:26:33 UTC 2019


> 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. <jackalmage at gmail.com> wrote:
> 
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <kaizhu256 at gmail.com> 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



More information about the es-discuss mailing list